DNS A record with https:// in the label












18














I recently encountered for the first time an A record of the form:



https://www.example.com.    <TTL>   IN  A   <IP address>


As far as I know, this record is deliberate (i.e. not an error). I know that the colon and forward-slash are valid characters for a label, per RFC 2181, but I don't understand the record's purpose. Does some certificate authority use this form for domain control validation? Does this form protect against some type of exploit? Trap some kind of user error or known issue with software?










share|improve this question


















  • 1




    Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
    – jcaron
    Nov 27 at 16:07










  • The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
    – Binky
    Nov 27 at 22:21












  • If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
    – Binky
    Nov 27 at 22:28










  • The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
    – Binky
    Nov 27 at 22:55












  • @Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
    – R..
    Nov 28 at 4:01
















18














I recently encountered for the first time an A record of the form:



https://www.example.com.    <TTL>   IN  A   <IP address>


As far as I know, this record is deliberate (i.e. not an error). I know that the colon and forward-slash are valid characters for a label, per RFC 2181, but I don't understand the record's purpose. Does some certificate authority use this form for domain control validation? Does this form protect against some type of exploit? Trap some kind of user error or known issue with software?










share|improve this question


















  • 1




    Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
    – jcaron
    Nov 27 at 16:07










  • The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
    – Binky
    Nov 27 at 22:21












  • If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
    – Binky
    Nov 27 at 22:28










  • The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
    – Binky
    Nov 27 at 22:55












  • @Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
    – R..
    Nov 28 at 4:01














18












18








18


1





I recently encountered for the first time an A record of the form:



https://www.example.com.    <TTL>   IN  A   <IP address>


As far as I know, this record is deliberate (i.e. not an error). I know that the colon and forward-slash are valid characters for a label, per RFC 2181, but I don't understand the record's purpose. Does some certificate authority use this form for domain control validation? Does this form protect against some type of exploit? Trap some kind of user error or known issue with software?










share|improve this question













I recently encountered for the first time an A record of the form:



https://www.example.com.    <TTL>   IN  A   <IP address>


As far as I know, this record is deliberate (i.e. not an error). I know that the colon and forward-slash are valid characters for a label, per RFC 2181, but I don't understand the record's purpose. Does some certificate authority use this form for domain control validation? Does this form protect against some type of exploit? Trap some kind of user error or known issue with software?







domain-name-system a-record






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 27 at 1:09









Binky

9116




9116








  • 1




    Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
    – jcaron
    Nov 27 at 16:07










  • The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
    – Binky
    Nov 27 at 22:21












  • If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
    – Binky
    Nov 27 at 22:28










  • The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
    – Binky
    Nov 27 at 22:55












  • @Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
    – R..
    Nov 28 at 4:01














  • 1




    Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
    – jcaron
    Nov 27 at 16:07










  • The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
    – Binky
    Nov 27 at 22:21












  • If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
    – Binky
    Nov 27 at 22:28










  • The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
    – Binky
    Nov 27 at 22:55












  • @Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
    – R..
    Nov 28 at 4:01








1




1




Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
– jcaron
Nov 27 at 16:07




Is the IP address different from the one for the matching www.example.com? What makes you think this is deliberate and not an error?
– jcaron
Nov 27 at 16:07












The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
– Binky
Nov 27 at 22:21






The reason I suspect this A record is not misconfigured is because the organization controlling these records is a major corporation with a large online presence, whose DNS records I would expect to be under significant scrutiny. But I am fully capable of believing that these A records are an error. I will dig (no pun intended) into this issue further and post an update if I determine the reason for the records.
– Binky
Nov 27 at 22:21














If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
– Binky
Nov 27 at 22:28




If anyone has a Farsight DNSDB account or a similar service, and would like to query the full DNS space for other A records having "https://", that'd be really cool. :)
– Binky
Nov 27 at 22:28












The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
– Binky
Nov 27 at 22:55






The IP address mapping of the A record for https://www.example.com is different from the the IP address mapping for www.example.com. The former maps to addresses (multiple A records) in the /16 netblock owned by "example.com" per ARIN whois. The latter maps to a CNAME in the domain of a major CDN provider. The CNAME chain ultimately maps to an IP address in the CDN provider's network
– Binky
Nov 27 at 22:55














@Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
– R..
Nov 28 at 4:01




@Binky: That is not a good reason to suspect it's not misconfigured. Incompetence in major corporations is extremely common.
– R..
Nov 28 at 4:01










2 Answers
2






active

oldest

votes


















50














The most likely explanation is a user unfamiliar with DNS tried to configure the DNS records and made a mistake that's glaringly obvious to anyone familiar with DNS, but not to people who aren't.



While a DNS label can be any arbitary binary data generally, you should read the rest of section 11, in particular:




Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose
whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values
returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.




Among other things, this means that the label syntax may be constrained depending on the RR type. As specified in RFC 1123 section 2.1 and RFC 952, Internet host names have such a constrained syntax, in which the colon and slash are not valid.






share|improve this answer































    1














    It's wrong for a standard address but it's possibly someone using DNS as a out of band communication device.



    It's not hard to imagine having to pass data via DNS instead of through 'normal' channels.






    share|improve this answer

















    • 1




      Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
      – Saiboogu
      Nov 27 at 19:20






    • 1




      it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
      – Binky
      Nov 27 at 22:32












    • @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
      – djsmiley2k
      Nov 28 at 9:11










    • This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
      – Criggie
      Nov 28 at 18:28











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "2"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f941735%2fdns-a-record-with-https-in-the-label%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    50














    The most likely explanation is a user unfamiliar with DNS tried to configure the DNS records and made a mistake that's glaringly obvious to anyone familiar with DNS, but not to people who aren't.



    While a DNS label can be any arbitary binary data generally, you should read the rest of section 11, in particular:




    Note however, that the various applications that make use of DNS data
    can have restrictions imposed on what particular values are
    acceptable in their environment. For example, that any binary label
    can have an MX record does not imply that any binary name can be used
    as the host part of an e-mail address. Clients of the DNS can impose
    whatever restrictions are appropriate to their circumstances on the
    values they use as keys for DNS lookup requests, and on the values
    returned by the DNS. If the client has such restrictions, it is
    solely responsible for validating the data from the DNS to ensure
    that it conforms before it makes any use of that data.




    Among other things, this means that the label syntax may be constrained depending on the RR type. As specified in RFC 1123 section 2.1 and RFC 952, Internet host names have such a constrained syntax, in which the colon and slash are not valid.






    share|improve this answer




























      50














      The most likely explanation is a user unfamiliar with DNS tried to configure the DNS records and made a mistake that's glaringly obvious to anyone familiar with DNS, but not to people who aren't.



      While a DNS label can be any arbitary binary data generally, you should read the rest of section 11, in particular:




      Note however, that the various applications that make use of DNS data
      can have restrictions imposed on what particular values are
      acceptable in their environment. For example, that any binary label
      can have an MX record does not imply that any binary name can be used
      as the host part of an e-mail address. Clients of the DNS can impose
      whatever restrictions are appropriate to their circumstances on the
      values they use as keys for DNS lookup requests, and on the values
      returned by the DNS. If the client has such restrictions, it is
      solely responsible for validating the data from the DNS to ensure
      that it conforms before it makes any use of that data.




      Among other things, this means that the label syntax may be constrained depending on the RR type. As specified in RFC 1123 section 2.1 and RFC 952, Internet host names have such a constrained syntax, in which the colon and slash are not valid.






      share|improve this answer


























        50












        50








        50






        The most likely explanation is a user unfamiliar with DNS tried to configure the DNS records and made a mistake that's glaringly obvious to anyone familiar with DNS, but not to people who aren't.



        While a DNS label can be any arbitary binary data generally, you should read the rest of section 11, in particular:




        Note however, that the various applications that make use of DNS data
        can have restrictions imposed on what particular values are
        acceptable in their environment. For example, that any binary label
        can have an MX record does not imply that any binary name can be used
        as the host part of an e-mail address. Clients of the DNS can impose
        whatever restrictions are appropriate to their circumstances on the
        values they use as keys for DNS lookup requests, and on the values
        returned by the DNS. If the client has such restrictions, it is
        solely responsible for validating the data from the DNS to ensure
        that it conforms before it makes any use of that data.




        Among other things, this means that the label syntax may be constrained depending on the RR type. As specified in RFC 1123 section 2.1 and RFC 952, Internet host names have such a constrained syntax, in which the colon and slash are not valid.






        share|improve this answer














        The most likely explanation is a user unfamiliar with DNS tried to configure the DNS records and made a mistake that's glaringly obvious to anyone familiar with DNS, but not to people who aren't.



        While a DNS label can be any arbitary binary data generally, you should read the rest of section 11, in particular:




        Note however, that the various applications that make use of DNS data
        can have restrictions imposed on what particular values are
        acceptable in their environment. For example, that any binary label
        can have an MX record does not imply that any binary name can be used
        as the host part of an e-mail address. Clients of the DNS can impose
        whatever restrictions are appropriate to their circumstances on the
        values they use as keys for DNS lookup requests, and on the values
        returned by the DNS. If the client has such restrictions, it is
        solely responsible for validating the data from the DNS to ensure
        that it conforms before it makes any use of that data.




        Among other things, this means that the label syntax may be constrained depending on the RR type. As specified in RFC 1123 section 2.1 and RFC 952, Internet host names have such a constrained syntax, in which the colon and slash are not valid.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 27 at 1:44

























        answered Nov 27 at 1:30









        Michael Hampton

        164k26304620




        164k26304620

























            1














            It's wrong for a standard address but it's possibly someone using DNS as a out of band communication device.



            It's not hard to imagine having to pass data via DNS instead of through 'normal' channels.






            share|improve this answer

















            • 1




              Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
              – Saiboogu
              Nov 27 at 19:20






            • 1




              it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
              – Binky
              Nov 27 at 22:32












            • @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
              – djsmiley2k
              Nov 28 at 9:11










            • This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
              – Criggie
              Nov 28 at 18:28
















            1














            It's wrong for a standard address but it's possibly someone using DNS as a out of band communication device.



            It's not hard to imagine having to pass data via DNS instead of through 'normal' channels.






            share|improve this answer

















            • 1




              Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
              – Saiboogu
              Nov 27 at 19:20






            • 1




              it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
              – Binky
              Nov 27 at 22:32












            • @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
              – djsmiley2k
              Nov 28 at 9:11










            • This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
              – Criggie
              Nov 28 at 18:28














            1












            1








            1






            It's wrong for a standard address but it's possibly someone using DNS as a out of band communication device.



            It's not hard to imagine having to pass data via DNS instead of through 'normal' channels.






            share|improve this answer












            It's wrong for a standard address but it's possibly someone using DNS as a out of band communication device.



            It's not hard to imagine having to pass data via DNS instead of through 'normal' channels.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 27 at 12:07









            djsmiley2k

            320211




            320211








            • 1




              Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
              – Saiboogu
              Nov 27 at 19:20






            • 1




              it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
              – Binky
              Nov 27 at 22:32












            • @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
              – djsmiley2k
              Nov 28 at 9:11










            • This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
              – Criggie
              Nov 28 at 18:28














            • 1




              Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
              – Saiboogu
              Nov 27 at 19:20






            • 1




              it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
              – Binky
              Nov 27 at 22:32












            • @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
              – djsmiley2k
              Nov 28 at 9:11










            • This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
              – Criggie
              Nov 28 at 18:28








            1




            1




            Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
            – Saiboogu
            Nov 27 at 19:20




            Could you go ahead and imagine for us? As it is this answer doesn't really say what might be happening - just that the answerer thinks it is logical.
            – Saiboogu
            Nov 27 at 19:20




            1




            1




            it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
            – Binky
            Nov 27 at 22:32






            it's possibly someone using DNS as a out of band communication device. @djsmiley2k I didn't mention this possibility in my original post because the organization controlling these A records is a corporation with substantial security/compliance requirements. For these records to be an out-of-band access mechanism would be highly unlikely, and if the records were an OOB hack, then the repercussions would be... scary.
            – Binky
            Nov 27 at 22:32














            @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
            – djsmiley2k
            Nov 28 at 9:11




            @Blinky fair enough, it's unlikely in this case, but it's a possibility in others.
            – djsmiley2k
            Nov 28 at 9:11












            This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
            – Criggie
            Nov 28 at 18:28




            This is certainly a possible thing, but DNS side channels are normally done with text in a TXT record, and not in the hostname itself. Additionally "https://" looks like an error, not a cyphered text.
            – Criggie
            Nov 28 at 18:28


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Server Fault!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f941735%2fdns-a-record-with-https-in-the-label%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Bundesstraße 106

            Verónica Boquete

            Ida-Boy-Ed-Garten