Re: per record responses based on originating IP
Hello I found that knot's geoip module can modify responses to individual records based on the source address of the client through the module's "net" directive and have successfully tested the modification of NS responses based on the client's source subnet - it seems to do exactly what I want. I had a quick check of the bind geoip module but the example given in the documentation suggests presenting an entire zone as an alternative view. Thanks for taking the time with me on my quest, but I think I'll further investigate knot at this time. knot geoip module overview: https://blog.apnic.net/2018/11/14/geoip-in-knot-dns-2-7/ Thanks Angus From: bind-users on behalf of Nick Tait via bind-users Sent: 16 May 2022 13:55 To: BIND Users Mailing List Subject: Re: per record responses based on originating IP On 16/05/22 20:05, Angus Clarke wrote: As mentioned in a separate reply to Grant, the goal is to have (amongst other things) local recursors "find" the locally deployed authoritative servers through NS records. What hasn't been mentioned is that I am also looking to simplify configuration management by means of a single set of data which can be deployed to all authoritative servers - I don't think the RPZ solution proposed by Nick achieves that. That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can. Hi Angus. Thanks for clarifying. Based on what you've said, what I proposed probably has slightly more merit than I concluded, although admittedly it doesn't quite tick all the boxes... Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I was specifying a single host which is why the RPZ-CLIENT-IP records all started with 32. Secondly, RPZs are more commonly used on recursive resolvers rather than the authoritative nameservers for the zone, although in your case if you are wanting to change the answer that an authoritative nameserver gives to the NS question from the recursive resolver, then it probably makes the most sense to put the RPZ on the authoritative nameserver. In this case you'd also need to specify "recursive-only no". (FYI Default behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.) However this still doesn't meet your requirement for "a single set of data", unless you are only talking about zone data, and in that case you could replicate all the RPZ zone files to all authoritative nameservers, and then configure each server to specify only one of these in its "response-policy" configuration? But the anycast suggestion sounds like it has the most merit? Or at least it sounds the coolest to me. :-) Nick. P.S. I don't think this will be useful to you, but FWIW... if your goal is simply to have the recursive resolvers use a specific subset of nameservers for specific zones, then there is yet another option: static-stub zones. Static-stub zones allow you to effectively override the authoritative nameserver that will be used for a particular zone. So you could configure the static-stub zone on the recursive resolver, and that would point to the local authoritative nameserver(s). However the main drawback with static-stub zones is that you need to create a static-stub zone (on the local resolver) for every authoritative zone that you are doing this with, so it probably isn't practical if you have many zones or are adding or removing zones frequently? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
On 16/05/22 20:05, Angus Clarke wrote: As mentioned in a separate reply to Grant, the goal is to have (amongst other things) local recursors "find" the locally deployed authoritative servers through NS records. What hasn't been mentioned is that I am also looking to simplify configuration management by means of a single set of data which can be deployed to all authoritative servers - I don't think the RPZ solution proposed by Nick achieves that. That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can. Hi Angus. Thanks for clarifying. Based on what you've said, what I proposed probably has slightly more merit than I concluded, although admittedly it doesn't quite tick all the boxes... Firstly, yes RPZ-CLIENT-IP can be a subnet. IPv4 addresses are represented as prefixlength.B4.B3.B2.B1.rpz-client-ip. In my examples I was specifying a single host which is why the RPZ-CLIENT-IP records all started with 32. Secondly, RPZs are more commonly used on recursive resolvers rather than the authoritative nameservers for the zone, although in your case if you are wanting to change the answer that an authoritative nameserver gives to the NS question from the recursive resolver, then it probably makes the most sense to put the RPZ on the authoritative nameserver. In this case you'd also need to specify "recursive-only no". (FYI Default behaviour is to apply RPZ rewriting to queries with RD=1 and DO=0.) However this still doesn't meet your requirement for "a single set of data", unless you are only talking about zone data, and in that case you could replicate all the RPZ zone files to all authoritative nameservers, and then configure each server to specify only one of these in its "response-policy" configuration? But the anycast suggestion sounds like it has the most merit? Or at least it sounds the coolest to me. :-) Nick. P.S. I don't think this will be useful to you, but FWIW... if your goal is simply to have the recursive resolvers use a specific subset of nameservers for specific zones, then there is yet another option: static-stub zones. Static-stub zones allow you to effectively override the authoritative nameserver that will be used for a particular zone. So you could configure the static-stub zone on the recursive resolver, and that would point to the local authoritative nameserver(s). However the main drawback with static-stub zones is that you need to create a static-stub zone (on the local resolver) for every authoritative zone that you are doing this with, so it probably isn't practical if you have many zones or are adding or removing zones frequently? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
Thanks for taking the time Nick and Grant, As mentioned in a separate reply to Grant, the goal is to have (amongst other things) local recursors "find" the locally deployed authoritative servers through NS records. What hasn't been mentioned is that I am also looking to simplify configuration management by means of a single set of data which can be deployed to all authoritative servers - I don't think the RPZ solution proposed by Nick achieves that. That being said, can RPZ-CLIENT-IP be a subnet? I don't think it can. So aside from the anycast suggestion, is there anything else I can look at with bind itself? - I didn't find much with respect to limiting a sortlist response to the first X responses. - Admittedly I don't very well understand the RPZ documentation but I get the feeling it is not the way to go. - Views seem to require duplications of the whole zonefile (this might be the only way to go) - I did find mention of "attach-cache" but this seems to be more about performance than anything else. I could create views for all of my networks - this is automatable. Thanks Angus From: bind-users on behalf of Nick Tait via bind-users Sent: 14 May 2022 02:34 To: bind-users@lists.isc.org Subject: Re: per record responses based on originating IP On 13/05/22 09:02, Grant Taylor via bind-users wrote: On 5/12/22 2:41 PM, Nick Tait via bind-users wrote: This sounds like exactly the sort of use case for Response Policy Zones: How are you going to have RPZ return different addresses for different clients? Are you suggesting use different RPZs with different contents for different clients? Yes, although now that I think through the details it turns out to be much messier than I first thought, because there doesn't seem to be a way to specify "not" in the RPZ... Also I should point out that I'm assuming that a PASSTHRU result in one RPZ will still result in subsequent RPZs being processed. I haven't actually tested this, so its possible I'm misunderstanding the documentation? Anyway in the interests of following this all the way though, let's assume you had 3 clients and you wanted them to each receive a different answer to the query "www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0>": Suppose their IP addresses are: A = 192.0.2.10 B = 192.0.2.20 C = 192.0.2.30 Then, if I'm not mistaken, you could create 3 RPZ zones: Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients B & C 32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> IN A 10.0.0.1 Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients A & C 32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> www.example.com<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.com%2F=05%7C01%7C%7C589fe7de17b74f5572de08da35419bf7%7C84df9e7fe9f640afb435%7C1%7C0%7C637880853152782803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lqcfFw8mM%2B5e9NEVLBLArSYuFjY6uZMRteO7BRyvlDU%3D=0> IN A 10.0.0.2 Zone file for "c.rpz.mylocaldomain.com" contains (in addition to
Re: per record responses based on originating IP
On 5/15/22 7:28 AM, Angus Clarke wrote: Hi Grant Hi Angus, maybe, I'm reading up ... poking around the manual, are you alluding to the "sortlist" directive? Yes, that's what I was referring to. So the concern with returning an ordered RRset is that the set could be large: Okay. I assume that's opposed to returning small distinct / unique RR sets with per client granularity. The intention is that each private site/network will have its own DNS server pair and that local recursors resolve all private zones from that local pair. So things like NS records would be in scope for the ordered RRset response. With more sites come more DNS pairs and therefore more NS records to be added to the RRset. Maybe I can limit a RRset response to the first X number of entries? Hum. With this description in mind, I'd be tempted to do something with the anycast methodology that was recently discussed. Return one small RRset that references the fixed set of any cast NS IPs. Then routing at each site will get clients to the local instance of those anycasted IPs. This would probably scale a lot better. Thanks :-) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
Hi Grant > Before stepping up to views I'd stop to ask the question, would > returning multiple IPs in a preferred sort order suffice? maybe, I'm reading up ... > BIND has the ability to sort RRs differently based on different client > criteria. poking around the manual, are you alluding to the "sortlist" directive? > If sorting of replies won't suffice, please provide a hypothetical > example of a couple of different clients & responses for an example RR. So the concern with returning an ordered RRset is that the set could be large: The intention is that each private site/network will have its own DNS server pair and that local recursors resolve all private zones from that local pair. So things like NS records would be in scope for the ordered RRset response. With more sites come more DNS pairs and therefore more NS records to be added to the RRset. Maybe I can limit a RRset response to the first X number of entries? Thanks Angus From: bind-users on behalf of Grant Taylor via bind-users Sent: 12 May 2022 18:11 To: bind-users@lists.isc.org Subject: Re: per record responses based on originating IP On 5/12/22 6:30 AM, Angus Clarke wrote: > Hello Hi, > With bind (and others) it seems that DNS views are the way to go, Before stepping up to views I'd stop to ask the question, would returning multiple IPs in a preferred sort order suffice? BIND has the ability to sort RRs differently based on different client criteria. > Does bind have some simple way to respond differently based on source > address but on a per record basis? Or perhaps include a baseline zone in > a view and separately include differences for that view - something like > this perhaps? If sorting of replies won't suffice, please provide a hypothetical example of a couple of different clients & responses for an example RR. -- Grant. . . . unix || die -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
On 13/05/22 09:02, Grant Taylor via bind-users wrote: On 5/12/22 2:41 PM, Nick Tait via bind-users wrote: This sounds like exactly the sort of use case for Response Policy Zones: How are you going to have RPZ return different addresses for different clients? Are you suggesting use different RPZs with different contents for different clients? Yes, although now that I think through the details it turns out to be much messier than I first thought, because there doesn't seem to be a way to specify "not" in the RPZ... Also I should point out that I'm assuming that a PASSTHRU result in one RPZ will still result in subsequent RPZs being processed. I haven't actually tested this, so its possible I'm misunderstanding the documentation? Anyway in the interests of following this all the way though, let's assume you had 3 clients and you wanted them to each receive a different answer to the query "www.example.com": Suppose their IP addresses are: A = 192.0.2.10 B = 192.0.2.20 C = 192.0.2.30 Then, if I'm not mistaken, you could create 3 RPZ zones: Zone file for "a.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients B & C 32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com www.example.com IN A 10.0.0.1 Zone file for "b.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients A & C 32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.30.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com www.example.com IN A 10.0.0.2 Zone file for "c.rpz.mylocaldomain.com" contains (in addition to SOA, etc): ; Don't overwrite the answer for queries received from clients A & B 32.10.2.0.192.rpz-client-ip IN CNAME rpz-passthru. 32.20.2.0.192.rpz-client-ip IN CNAME rpz-passthru. ; Change the answer to the question www.example.com www.example.com IN A 10.0.0.3 And then configure BIND to use all three RPZs: response-policy { zone "a.rpz.mylocaldomain.com"; zone "b.rpz.mylocaldomain.com"; zone "c.rpz.mylocaldomain.com"; }; Scalability is obviously a challenge with this particular solution! :-( So on reflection, there are probably better solutions to the problem that you are trying to solve. Although I don't personally have experience with it, wonder if "dnsmasq" might do what you need? Thanks, Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
On 5/12/22 2:41 PM, Nick Tait via bind-users wrote: This sounds like exactly the sort of use case for Response Policy Zones: How are you going to have RPZ return different addresses for different clients? Are you suggesting use different RPZs with different contents for different clients? -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
On 13/05/2022 12:30 am, Angus Clarke wrote: Does bind have some simple way to respond differently based on source address but on a per record basis? Or perhaps include a baseline zone in a view and separately include differences for that view - something like this perhaps? Hi Angus. This sounds like exactly the sort of use case for Response Policy Zones: https://bind9.readthedocs.io/en/v9_18_2/reference.html#response-policy-zone-rpz-rewriting Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: per record responses based on originating IP
On 5/12/22 6:30 AM, Angus Clarke wrote: Hello Hi, With bind (and others) it seems that DNS views are the way to go, Before stepping up to views I'd stop to ask the question, would returning multiple IPs in a preferred sort order suffice? BIND has the ability to sort RRs differently based on different client criteria. Does bind have some simple way to respond differently based on source address but on a per record basis? Or perhaps include a baseline zone in a view and separately include differences for that view - something like this perhaps? If sorting of replies won't suffice, please provide a hypothetical example of a couple of different clients & responses for an example RR. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record for @?
@lbutlr via bind-users wrote: > I have a domain that I hot DNS and email for, but not web. I set the A > record for www.example.com to the IP of the web server with nsupdate, > removing the old CNAME the pointed to the local webserver, but the web > monkey for the new website is saying that www has to be a CNAME and the > @ record should be the A record pointing to the IP. You can do that, but it might have weird effects if someone tries to send email to someth...@www.example.com. I generally think it's neater for both the zone file origin (aka @) and the www subdomain to have A/ records pointing at the web server. > I don't think this is right, and if it is I am not sure how to use > nsupdate to make this change. @ is just an abbreviation for (in this case) example.com (it's handy for writing instructions or zone file that work the same for any domain name). In cases where there isn't an implicit origin, such as nsupdate, you need to write the records out in full instead, e.g. www.example.com. CNAME example.com. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Foreland to Selsey Bill: Northwesterly, backing westerly or southwesterly 3 or 4, increasing 4 to 6 later. Smooth or slight, occasionally moderate later. Showers later. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Record Server Availability
Well mDNS is not DNS. It is a multicast request to all devices on the local network to respond. To get the functionality being requested in the DNS it requires something to be polling the availability of the server listed in the SRV records and to add/remove/adjust them depending upon their load/availability. In reality this should not be needed if people would just write client software to properly handle multi-homed servers. There is nothing that say you must wait for a connection to timeout before you attempt to connect to a second address. Happy Eyeballs RFC 8305 (previously RFC 6555) us about starting multiple connections across address families and only proceeding with the first that connects but there is NOTHING that says you can’t do the similar for all addresses independent of address family. It isn’t hard to write a TCP client that attempts to connect to multiple servers simultaneously. I will admit that it is slightly harder for UDP clients but in most cases it is not impossible. For both protocols you do not wait seconds to get the initial response before trying the alternate addresses. Most of the world is less that 300ms way (round trip). Mark > On 7 Jan 2021, at 03:42, Andrew P. wrote: > > Isn't this sort of dynamic functionality (real-time presence or absence of > SRV records) what mDNS and the avahi daemon are for? > > > From: bind-users on behalf of Matus UHLAR > - fantomas > Sent: Wednesday, January 6, 2021 8:51 AM > To: bind-users@lists.isc.org > Subject: Re: SRV Record Server Availability > > On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote: >> Your understanding is correct, i just thought that SRV can detect whose >> server is alive so it can choose and provide an answer with the available >> Server. > > DNS is not designed to provide this functionality. While technically you can > change contents of DNS depending on which servers are alive and which are > not, it's almost never a good idea. > > That means, BIND has nothing like this built in. > >>> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users >>> wrote: >>>> Is DNS Bind SRV record can detect the Server's availability? If yes, how? > >> On Tue, 5 Jan 2021, 23:53 tale wrote: >>> Could you provide more information about your goal? I don't fully >>> understand the question. >>> >>> For my reading, the answer is basically no, in that an SRV record just >>> provides data about where.a particular service can be found. It's up >>> to other systems to fetch that data and interpret it, including >>> whether that service is actually available at the given endpoint. In >>> its typical operation, BIND will just take whatever name and port the >>> zone administrator said to provide for that SRV record, and not do any >>> sort of availability checks on it. >>> >>> However, if you go deep into a far more complicated, custom use of >>> BIND, you could set up a process that monitors the availability and >>> changes the SRV record accordingly. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Microsoft dick is soft to do no harm > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Record Server Availability
Isn't this sort of dynamic functionality (real-time presence or absence of SRV records) what mDNS and the avahi daemon are for? From: bind-users on behalf of Matus UHLAR - fantomas Sent: Wednesday, January 6, 2021 8:51 AM To: bind-users@lists.isc.org Subject: Re: SRV Record Server Availability On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote: >Your understanding is correct, i just thought that SRV can detect whose >server is alive so it can choose and provide an answer with the available >Server. DNS is not designed to provide this functionality. While technically you can change contents of DNS depending on which servers are alive and which are not, it's almost never a good idea. That means, BIND has nothing like this built in. >> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users >> wrote: >> > Is DNS Bind SRV record can detect the Server's availability? If yes, how? >On Tue, 5 Jan 2021, 23:53 tale wrote: >> Could you provide more information about your goal? I don't fully >> understand the question. >> >> For my reading, the answer is basically no, in that an SRV record just >> provides data about where.a particular service can be found. It's up >> to other systems to fetch that data and interpret it, including >> whether that service is actually available at the given endpoint. In >> its typical operation, BIND will just take whatever name and port the >> zone administrator said to provide for that SRV record, and not do any >> sort of availability checks on it. >> >> However, if you go deep into a far more complicated, custom use of >> BIND, you could set up a process that monitors the availability and >> changes the SRV record accordingly. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Record Server Availability
On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote: Your understanding is correct, i just thought that SRV can detect whose server is alive so it can choose and provide an answer with the available Server. DNS is not designed to provide this functionality. While technically you can change contents of DNS depending on which servers are alive and which are not, it's almost never a good idea. That means, BIND has nothing like this built in. On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users wrote: > Is DNS Bind SRV record can detect the Server's availability? If yes, how? On Tue, 5 Jan 2021, 23:53 tale wrote: Could you provide more information about your goal? I don't fully understand the question. For my reading, the answer is basically no, in that an SRV record just provides data about where.a particular service can be found. It's up to other systems to fetch that data and interpret it, including whether that service is actually available at the given endpoint. In its typical operation, BIND will just take whatever name and port the zone administrator said to provide for that SRV record, and not do any sort of availability checks on it. However, if you go deep into a far more complicated, custom use of BIND, you could set up a process that monitors the availability and changes the SRV record accordingly. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Record Server Availability
Hi Tale, Happy new year! Your understanding is correct, i just thought that SRV can detect whose server is alive so it can choose and provide an answer with the available Server. Thank you! On Tue, 5 Jan 2021, 23:53 tale wrote: > On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users > wrote: > > Is DNS Bind SRV record can detect the Server's availability? If yes, how? > > Could you provide more information about your goal? I don't fully > understand the question. > > For my reading, the answer is basically no, in that an SRV record just > provides data about where.a particular service can be found. It's up > to other systems to fetch that data and interpret it, including > whether that service is actually available at the given endpoint. In > its typical operation, BIND will just take whatever name and port the > zone administrator said to provide for that SRV record, and not do any > sort of availability checks on it. > > However, if you go deep into a far more complicated, custom use of > BIND, you could set up a process that monitors the availability and > changes the SRV record accordingly. > -- > tale > -- This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV Record Server Availability
On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users wrote: > Is DNS Bind SRV record can detect the Server's availability? If yes, how? Could you provide more information about your goal? I don't fully understand the question. For my reading, the answer is basically no, in that an SRV record just provides data about where.a particular service can be found. It's up to other systems to fetch that data and interpret it, including whether that service is actually available at the given endpoint. In its typical operation, BIND will just take whatever name and port the zone administrator said to provide for that SRV record, and not do any sort of availability checks on it. However, if you go deep into a far more complicated, custom use of BIND, you could set up a process that monitors the availability and changes the SRV record accordingly. -- tale ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Tony, Thank you for that detailed explanation. On Wed, Jul 3, 2019 at 2:15 AM Tony Finch wrote: > Josh Kuo wrote: > > > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > > that the single RRSIG is generated by somehow concatenating all DS > records > > together. > > Correct. > > > This then leads me to believe that the validating resolver needs to > > process _all_ DS records, not just the ones whose key tag matches the > > child zone's KSK. > > Not quite. > > One way to validate a delegation is: > > * validate the DS RRset, which is signed using the parent's DNSKEY(s) > [ you can see the "com" signer field in the "example.com" RRSIG ] > > * get the key tags from the DS RRset (the first field in the records) > and the key tags from the child's DNSKEY RRSIG records (between lifetime > fields and the signer field) and calculate the key tags of the > child's DNSKEY records > > * take the intersection of these three sets; these key tags identify keys > that the parent says can validate the DNSKEY RRset, and that actually do > validate the DNSKEY RRset, and that can be used to validate the DNSKEY > RRset > > * for each DNSKEY in the set, ensure that there is a DS record that > whose digest matches it [ you can skip matching attempts when the key > tags do not match ] > > * using the public keys and signatures you just identified, try to > validate the self-signature on the DNSKEY RRset; if any of the > signatures validates, it's all good! [ again the key tags let you > skip pointless signature validation attempts ] > > There are some extra complications to do with downgrade protection, but > that's the basic idea. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > women and men working together > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Josh Kuo wrote: > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > that the single RRSIG is generated by somehow concatenating all DS records > together. Correct. > This then leads me to believe that the validating resolver needs to > process _all_ DS records, not just the ones whose key tag matches the > child zone's KSK. Not quite. One way to validate a delegation is: * validate the DS RRset, which is signed using the parent's DNSKEY(s) [ you can see the "com" signer field in the "example.com" RRSIG ] * get the key tags from the DS RRset (the first field in the records) and the key tags from the child's DNSKEY RRSIG records (between lifetime fields and the signer field) and calculate the key tags of the child's DNSKEY records * take the intersection of these three sets; these key tags identify keys that the parent says can validate the DNSKEY RRset, and that actually do validate the DNSKEY RRset, and that can be used to validate the DNSKEY RRset * for each DNSKEY in the set, ensure that there is a DS record that whose digest matches it [ you can skip matching attempts when the key tags do not match ] * using the public keys and signatures you just identified, try to validate the self-signature on the DNSKEY RRset; if any of the signatures validates, it's all good! [ again the key tags let you skip pointless signature validation attempts ] There are some extra complications to do with downgrade protection, but that's the basic idea. Tony. -- f.anthony.n.finchhttp://dotat.at/ women and men working together ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Thank you for the clarification. On Wed, Jul 3, 2019 at 1:49 AM Ondřej Surý wrote: > Yes, the whole RRSet is always signed. Signing individual records would > not protect against attacks stripping individual records and their RRSIGs. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 2 Jul 2019, at 19:34, Josh Kuo wrote: > > > > This may not be the right place to ask, if this is a better question > asked in a different list, please let me know. > > > > I am curious as to how BIND generates and processes DS RRSIG, and this > may not be unique to BIND, since I've seen this behavior across multiple > vendors. From the following: > > > > $ dig example.com. DS +dnssec +nocrypto > > > > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 > > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 4096 > > ;; QUESTION SECTION: > > ;example.com. IN DS > > > > ;; ANSWER SECTION: > > example.com. 84558 IN DS 43547 8 2 [omitted] > > example.com. 84558 IN DS 31406 8 1 [omitted] > > example.com. 84558 IN DS 31406 8 2 [omitted] > > example.com. 84558 IN DS 31589 8 1 [omitted] > > example.com. 84558 IN DS 31589 8 2 [omitted] > > example.com. 84558 IN DS 43547 8 1 [omitted] > > example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 > 20190702031256 3800 com. [omitted] > > > > ;; Query time: 228 msec > > ;; SERVER: 10.0.22.1#53(10.0.22.1) > > ;; WHEN: Wed Jul 03 01:27:42 PST 2019 > > ;; MSG SIZE rcvd: 455 > > > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > that the single RRSIG is generated by somehow concatenating all DS records > together. This then leads me to believe that the validating resolver needs > to process _all_ DS records, not just the ones whose key tag matches the > child zone's KSK. Is this true? It seems like a small overhead in the grand > scheme of things, but that seems inefficient, if multiple DS records are > left at the parent zone after a couple of key rollovers. > > > > Any information on this would be appreciated. > > > > -Josh > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Yes, the whole RRSet is always signed. Signing individual records would not protect against attacks stripping individual records and their RRSIGs. Ondrej -- Ondřej Surý ond...@isc.org > On 2 Jul 2019, at 19:34, Josh Kuo wrote: > > This may not be the right place to ask, if this is a better question asked in > a different list, please let me know. > > I am curious as to how BIND generates and processes DS RRSIG, and this may > not be unique to BIND, since I've seen this behavior across multiple vendors. > From the following: > > $ dig example.com. DS +dnssec +nocrypto > > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;example.com. IN DS > > ;; ANSWER SECTION: > example.com. 84558 IN DS 43547 8 2 [omitted] > example.com. 84558 IN DS 31406 8 1 [omitted] > example.com. 84558 IN DS 31406 8 2 [omitted] > example.com. 84558 IN DS 31589 8 1 [omitted] > example.com. 84558 IN DS 31589 8 2 [omitted] > example.com. 84558 IN DS 43547 8 1 [omitted] > example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 > 20190702031256 3800 com. [omitted] > > ;; Query time: 228 msec > ;; SERVER: 10.0.22.1#53(10.0.22.1) > ;; WHEN: Wed Jul 03 01:27:42 PST 2019 > ;; MSG SIZE rcvd: 455 > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe that > the single RRSIG is generated by somehow concatenating all DS records > together. This then leads me to believe that the validating resolver needs to > process _all_ DS records, not just the ones whose key tag matches the child > zone's KSK. Is this true? It seems like a small overhead in the grand scheme > of things, but that seems inefficient, if multiple DS records are left at the > parent zone after a couple of key rollovers. > > Any information on this would be appreciated. > > -Josh > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
On 8/18/18, Doug Barton wrote: > On 08/18/2018 04:53 PM, Barry Margolin wrote: >> In article , >> Grant Taylor wrote: >> >>> On 08/18/2018 07:25 AM, Bob McDonald wrote: I don't think anyone hates nslookup (well maybe a few do ) I suppose the immense dislike stems from the fact that it's the default utility under Windows. Folks who use dig as their default realize that when used properly, dig provides much more functionality than nslookup. For example, try using TSIG with nslookup or getting a NSID response. These are only a couple of examples. There's other reasons to change. The output from dig is much more comprehensive. And, yes, if you install the bind tools from ISC under Windows, dig works quite well. >>> >>> I've been told that nslookup will lie and provide incorrect information >>> in some situations. I have no idea what situations that is. I would >>> love to learn what they are. >>> >>> If you know of such an example, please enlighten me. >>> >>> As such, I tend to use nslookup on platforms without dig when or until I >>> have reason to not do so. >> >> I don't think it "lies" much, but the output isn't as clear and >> unambiguous as dig's. When it reports errors, it can be difficult to >> tell specifically what the actual error was. >> >> One example I can think of is that for some reason it expects the >> nameserver to be able to reverse-resolve its own IP. If it can't, it >> reports this as an error, and you might think that it's reporting an >> error about the name you're actually trying to look up. > > nslookup uses the local resolver stub. That's fine, if that's what you > want/need to test. If you want to test specific servers, or what is > visible from the Internet, etc. dig is the right tool, as the answers > you get from nslookup cannot be guaranteed to be directly related to the > question you asked. Could you expand on that a bit please? I thought nslookup was pretty much equivalent to dig @ the exception being that nslookup looks for a & records and dig just looks for a records Thanks, Lee ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
On 08/18/2018 04:53 PM, Barry Margolin wrote: In article , Grant Taylor wrote: On 08/18/2018 07:25 AM, Bob McDonald wrote: I don't think anyone hates nslookup (well maybe a few do ) I suppose the immense dislike stems from the fact that it's the default utility under Windows. Folks who use dig as their default realize that when used properly, dig provides much more functionality than nslookup. For example, try using TSIG with nslookup or getting a NSID response. These are only a couple of examples. There's other reasons to change. The output from dig is much more comprehensive. And, yes, if you install the bind tools from ISC under Windows, dig works quite well. I've been told that nslookup will lie and provide incorrect information in some situations. I have no idea what situations that is. I would love to learn what they are. If you know of such an example, please enlighten me. As such, I tend to use nslookup on platforms without dig when or until I have reason to not do so. I don't think it "lies" much, but the output isn't as clear and unambiguous as dig's. When it reports errors, it can be difficult to tell specifically what the actual error was. One example I can think of is that for some reason it expects the nameserver to be able to reverse-resolve its own IP. If it can't, it reports this as an error, and you might think that it's reporting an error about the name you're actually trying to look up. nslookup uses the local resolver stub. That's fine, if that's what you want/need to test. If you want to test specific servers, or what is visible from the Internet, etc. dig is the right tool, as the answers you get from nslookup cannot be guaranteed to be directly related to the question you asked. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
In article , Grant Taylor wrote: > On 08/18/2018 07:25 AM, Bob McDonald wrote: > > I don't think anyone hates nslookup (well maybe a few do ) I > > suppose the immense dislike stems from the fact that it's the default > > utility under Windows. Folks who use dig as their default realize that > > when used properly, dig provides much more functionality than nslookup. > > For example, try using TSIG with nslookup or getting a NSID response. > > These are only a couple of examples. There's other reasons to change. > > The output from dig is much more comprehensive. And, yes, if you install > > the bind tools from ISC under Windows, dig works quite well. > > I've been told that nslookup will lie and provide incorrect information > in some situations. I have no idea what situations that is. I would > love to learn what they are. > > If you know of such an example, please enlighten me. > > As such, I tend to use nslookup on platforms without dig when or until I > have reason to not do so. I don't think it "lies" much, but the output isn't as clear and unambiguous as dig's. When it reports errors, it can be difficult to tell specifically what the actual error was. One example I can think of is that for some reason it expects the nameserver to be able to reverse-resolve its own IP. If it can't, it reports this as an error, and you might think that it's reporting an error about the name you're actually trying to look up. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
Extra complexity -- "man dig" yields 289 lines while "man nslookup" yields only 160 lines. Also, dig is not simply an extension of nslookup (which I long ago abbreviated to nsl), but is significantly different, so it using it involves the human analog of a cache miss. On Sat, 18 Aug 2018 20:12:01 +0200 Reindl Harald wrote: > > > Am 18.08.2018 um 20:02 schrieb Paul Kosinski: > > When I started using Linux almost 20 years ago, I think there was > > only nslookup, and no dig. So by habit, I tend to use it unless the > > extra power of dig outweighs its extra complexity. > > which extra complexity? > > because you have to add an @ when you want to use a non-default > nameserver and that you need "dig -X" for a reverse-lookup? > > you can use dig as nslookup, it's not required that you add a record > type - just "dig whatever" which is in that case even shorter > > > On Sat, 18 Aug 2018 11:42:20 -0600 > > Grant Taylor via bind-users wrote: > > > >> On 08/18/2018 07:25 AM, Bob McDonald wrote: > >>> I don't think anyone hates nslookup (well maybe a few do ) > >>> I suppose the immense dislike stems from the fact that it's the > >>> default utility under Windows. Folks who use dig as their default > >>> realize that when used properly, dig provides much more > >>> functionality than nslookup. For example, try using TSIG with > >>> nslookup or getting a NSID response. These are only a couple of > >>> examples. There's other reasons to change. The output from dig is > >>> much more comprehensive. And, yes, if you install the bind tools > >>> from ISC under Windows, dig works quite well. > >> > >> I've been told that nslookup will lie and provide incorrect > >> information in some situations. I have no idea what situations > >> that is. I would love to learn what they are. > >> > >> If you know of such an example, please enlighten me. > >> > >> As such, I tend to use nslookup on platforms without dig when or > >> until I have reason to not do so > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
When I started using Linux almost 20 years ago, I think there was only nslookup, and no dig. So by habit, I tend to use it unless the extra power of dig outweighs its extra complexity. I don't remember what I used on Windows back when I was regularly using both. On Sat, 18 Aug 2018 11:42:20 -0600 Grant Taylor via bind-users wrote: > On 08/18/2018 07:25 AM, Bob McDonald wrote: > > I don't think anyone hates nslookup (well maybe a few do ) I > > suppose the immense dislike stems from the fact that it's the > > default utility under Windows. Folks who use dig as their default > > realize that when used properly, dig provides much more > > functionality than nslookup. For example, try using TSIG with > > nslookup or getting a NSID response. These are only a couple of > > examples. There's other reasons to change. The output from dig is > > much more comprehensive. And, yes, if you install the bind tools > > from ISC under Windows, dig works quite well. > > I've been told that nslookup will lie and provide incorrect > information in some situations. I have no idea what situations that > is. I would love to learn what they are. > > If you know of such an example, please enlighten me. > > As such, I tend to use nslookup on platforms without dig when or > until I have reason to not do so. > > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
On 08/18/2018 07:25 AM, Bob McDonald wrote: I don't think anyone hates nslookup (well maybe a few do ) I suppose the immense dislike stems from the fact that it's the default utility under Windows. Folks who use dig as their default realize that when used properly, dig provides much more functionality than nslookup. For example, try using TSIG with nslookup or getting a NSID response. These are only a couple of examples. There's other reasons to change. The output from dig is much more comprehensive. And, yes, if you install the bind tools from ISC under Windows, dig works quite well. I've been told that nslookup will lie and provide incorrect information in some situations. I have no idea what situations that is. I would love to learn what they are. If you know of such an example, please enlighten me. As such, I tend to use nslookup on platforms without dig when or until I have reason to not do so. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
re: SRV record not working
> I know that most of you hate nslookup but I have been using it since the > 90's and it's my go-to utility. I get the same responses whether I use > Dig or nslookup. If nslookup doesn't return what I am looking for, I do > use Dig also. I don't think anyone hates nslookup (well maybe a few do ) I suppose the immense dislike stems from the fact that it's the default utility under Windows. Folks who use dig as their default realize that when used properly, dig provides much more functionality than nslookup. For example, try using TSIG with nslookup or getting a NSID response. These are only a couple of examples. There's other reasons to change. The output from dig is much more comprehensive. And, yes, if you install the bind tools from ISC under Windows, dig works quite well. Just my $.02 Bob ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
Seems ok here using: dig +trace srv _minecraft._tcp.skyblock.mc-game.us. mc-game.us. 3600IN NS ns1.sleepyvalley.net. mc-game.us. 3600IN NS sdns2.ovh.ca. ;; Received 113 bytes from 156.154.126.70#53(156.154.126.70) in 168 ms _minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc-game.us. ;; Received 92 bytes from 167.114.154.31#53(167.114.154.31) in 73 ms On Fri, Aug 17, 2018 at 10:42 AM, Carl Byington wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Fri, 2018-08-17 at 12:27 -0500, Thomas Strike wrote: > > I need a 2nd pair of eyes on this one. > > Works for me. > > dig _minecraft._tcp.skyblock.mc-game.us srv > > ;; ANSWER SECTION: > _minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc- > game.us. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAlt3CPAACgkQL6j7milTFsHoywCfRQIVqUZnycWdYGdRupaSEWiU > ZlsAn18No1vPczhoAURmolzbt3Z+I7PU > =EQx5 > -END PGP SIGNATURE- > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Peace, Joe "Without love in the dream It will never come true" Words by Robert Hunter ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2018-08-17 at 12:27 -0500, Thomas Strike wrote: > I need a 2nd pair of eyes on this one. Works for me. dig _minecraft._tcp.skyblock.mc-game.us srv ;; ANSWER SECTION: _minecraft._tcp.skyblock.mc-game.us. 300 IN SRV 0 5 25567 skyblock.mc- game.us. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlt3CPAACgkQL6j7milTFsHoywCfRQIVqUZnycWdYGdRupaSEWiU ZlsAn18No1vPczhoAURmolzbt3Z+I7PU =EQx5 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
On Fri, Aug 17, 2018 at 1:28 PM Thomas Strike wrote: > I have created a SRV record for a new subdomain A record. I set nslookup > to use my DNS server directly and when I query for the A record it > returns it. When I set type=SRV and ask for the srv record nothing is > returned. > > My SRV record: _minecraft._tcp.skyblock.mc-game.us.IN SRV0 5 > 25567 skyblock.mc-game.us. > > I need a 2nd pair of eyes on this one. > > Thanks, Tom Strike > > Works for me: nslookup -q=srv _minecraft._tcp.skyblock.mc-game.us. 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: _minecraft._tcp.skyblock.mc-game.us service = 0 5 25567 skyblock.mc-game.us. Authoritative answers can be found from: dig srv _minecraft._tcp.skyblock.mc-game.us. @8.8.8.8 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> srv _minecraft._tcp.skyblock.mc-game.us. @ 8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;_minecraft._tcp.skyblock.mc-game.us. IN SRV ;; ANSWER SECTION: _minecraft._tcp.skyblock.mc-game.us. 299 IN SRV 0 5 25567 skyblock.mc-game.us. ;; Query time: 56 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Aug 17 13:38:35 EDT 2018 ;; MSG SIZE rcvd: 103 -- Bob Harold ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SOA record not signed with new key at key-rollover
Am 18.07.2016 um 12:48 schrieb Tony Finch: > If your rollover time is much shorter then you are testing something that > is more like an emergency unplanned rollover. At the moment I am merely testing in this "high-frequency" setup to get a good feeling for the mechanics and the interaction between the tools. I understand that this is not the correct approach for a stable zone. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SOA record not signed with new key at key-rollover
Nis Wechselbergwrote: > Am I getting it right that the rest of the zone is not (re)signed > because the current signature is still valid for some time? > > So if I were to set sig-validity-interval to a shorter value, this would > help with the issue? If you are testing out a fast rollover schedule then it would make sense to set a short sig-validity-interval, scaled to match. If your rollover time is much shorter then you are testing something that is more like an emergency unplanned rollover. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Irish Sea: Southerly, becoming variable, 3 or 4, occasionally 5 at first in west. Smooth or slight. Fog banks. Moderate or good, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SOA record not signed with new key at key-rollover
Hi, you are right, I got confused there. Am I getting it right that the rest of the zone is not (re)signed because the current signature is still valid for some time? So if I were to set sig-validity-interval to a shorter value, this would help with the issue? Sadly it seems to be a value in days, so it is not that easy to test. I will try setting the interval to 1 day with 23 hours preview signing. Thanks. Am 17.07.2016 um 06:06 schrieb Mark Andrews: > In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes: >> Hi, >> >> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I >> created a test zone with very fast key rollover setings and very short >> TTLs. (Configs below) >> >> The automated creation of keys seems to work fine but bind behaves other >> than I would have expected. >> >> - Initial deployment looks fine with the current ZSK published and in use. >> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/) > > ZSK = 36141 > >> - At prepublication time the next key is published but not yet used (as >> expected. >> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/) > > New ZSK is 10173 > >> - After rollover time the new key is used to sign the zone EXCEPT the >> SOA record. This one is still signed by the old key. >> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/) > > No. The new ZSK signs the SOA record. The old signatures still exist > on the other records as the only RRset that changes is the SOA. > >> - When post-publication of the old key expires it is removed and the new >> key is used for all records. >> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/) >> >> >> I am confused becaus of the special treatment of the SOA record. I would >> expect a complete switch to the new key. At the moment, cached responses >> of the SOA record could not be verified in the timeframe between >> deletion of the old key and the next TTL. >> >> Am I missing something? >> >> Regards, >> Nis >> >> >> >> >> dnssec-keymgr policy: >> >> zone testmichhartundwild.de { >> algorithm RSASHA256; >> directory "/etc/bind/zones/keys"; >> coverage 2d; >> keyttl 600; >> roll-period zsk 8h; >> post-publish zsk 2h; >> pre-publish zsk 2h; >> }; >> >> >> bind zone config: >> >> zone "testmichhartundwild.de" IN { >> type master; >> >> file "de/testmichhartundwild.de/zone.db"; >> >> // Allow zone transfers to trusted servers >> allow-transfer { >> myServers; >> localhost; >> }; >> >> // Allow updates with shared key >> update-policy { >> grant morpheus-trinity. zonesub any; >> }; >> serial-update-method unixtime; >> >> // Activate dnssec for this domain >> key-directory "keys"; >> auto-dnssec maintain; >> }; >> >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe >> from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SOA record not signed with new key at key-rollover
In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes: > Hi, > > I am curently testing a dnssec setup with the new dnssec-keymgr tool. I > created a test zone with very fast key rollover setings and very short > TTLs. (Configs below) > > The automated creation of keys seems to work fine but bind behaves other > than I would have expected. > > - Initial deployment looks fine with the current ZSK published and in use. > (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/) ZSK = 36141 > - At prepublication time the next key is published but not yet used (as > expected. > (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/) New ZSK is 10173 > - After rollover time the new key is used to sign the zone EXCEPT the > SOA record. This one is still signed by the old key. > (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/) No. The new ZSK signs the SOA record. The old signatures still exist on the other records as the only RRset that changes is the SOA. > - When post-publication of the old key expires it is removed and the new > key is used for all records. > (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/) > > > I am confused becaus of the special treatment of the SOA record. I would > expect a complete switch to the new key. At the moment, cached responses > of the SOA record could not be verified in the timeframe between > deletion of the old key and the next TTL. > > Am I missing something? > > Regards, > Nis > > > > > dnssec-keymgr policy: > > zone testmichhartundwild.de { > algorithm RSASHA256; > directory "/etc/bind/zones/keys"; > coverage 2d; > keyttl 600; > roll-period zsk 8h; > post-publish zsk 2h; > pre-publish zsk 2h; > }; > > > bind zone config: > > zone "testmichhartundwild.de" IN { > type master; > > file "de/testmichhartundwild.de/zone.db"; > > // Allow zone transfers to trusted servers > allow-transfer { > myServers; > localhost; > }; > > // Allow updates with shared key > update-policy { > grant morpheus-trinity. zonesub any; > }; > serial-update-method unixtime; > > // Activate dnssec for this domain > key-directory "keys"; > auto-dnssec maintain; > }; > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record update via nsupdate
In message <7966c1a9-a930-b748-7e09-531304b4d...@rotld.ro>, Catalin Leanca writes: > > Hello, > > When using nsupdate command to update DS records for subdomains > without NS delegation, no error code is returned by command and also > no errors appear in BIND logs (and DS is not updated in the zone). > Is this a normal behavior? Yes. It is consistent with other UPDATE (RFC 2136) behaviours which maintain zone consistancy. UPDATE is silent about lots of things w/o explict prerequisites. > How to make BIND to issue errors when this happen ? Add a prerequisite that a NS rrset exists at the name. It the prerequiste fails you will get a error. > Best regards, > > -- > > *CS Catalin LEANCA* > ICI ROTLD - Serviciul Tehnic > Bd. Maresal Averescu 8-10, > Sector 1, Bucuresti > Mobil: +40 744 81 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Forward record for WWW
Stanley, > Are you running DNSSEC? Negative, we are not running dnssec. Brian ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward record for WWW
Are you running DNSSEC? Stanley Weilnau > On May 5, 2016, at 3:30 PM, Cuttler, Brian R. (HEALTH) > <brian.cutt...@health.ny.gov> wrote: > > Ralf, All, > > Sorry, there was a brief side discussion. A couple of years ago we > implemented a test server, same platform (in this case cloned virtual > systems) with same source tables and config, running in the same environment, > in this case my DMZ. > > Because I didn't want to risk damage to the master, as we have corrupted > tables and crashed servers, we implement changes on the test server, and if > it works as expected we rsync the updated tables to the live master from the > test master. > > Someone else reported a problem with dig to my server, and I'd thought the > list was CC'd, but the test is 199.184.16.7 and is apparently blocked at the > FW, as the test master and the actual master both live in the DMZ but the > test machine does not normally need to be seen from outside. > > My - what an extraordinary result! > > Looking again at the SOA from dig, included below we see 1604xxx, an April > date "YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a > March date, 1603xxx (yes, I have a script that subs that in when I move the > tables from the source to the root directory, complex combo of RCS, followed > by # SED as RCS doesn't provide integer revision numbers and an # rsync to > the directory read by the daemon, all on my test machine. If that all checks > out, an rsync from the test machine live (rather than source) directory to > the live directory on the actual master server). > > In any case, I stopped and started the server, and the A record is now being > reported. > > So, for reasons I don't understand, the SOA as reported by DIG does not match > the SOA serial imbedded in the file and reported by the server log. > > We solved my first problem, but I am now very confused by the apparent cause. > > I have run the rsync from my test server to my production master, reloaded > the tables, reloaded the tables. I see the same SOA as the test server (I > rsync the tables with no changes, SOA on my test and production servers is > the same), in the named logs, in DIG output, in the source files. > > Something is a bit hinky with my test server and I've no idea what. > > If anyone has any suggestions I'd love to hear them, but with your help the > issue I was having has been resolved by restarting the server, rather than > reloading the zones files. > > Many thanks, > Brian > >> -Original Message- >> From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov] >> Sent: Thursday, May 05, 2016 3:03 PM >> To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov> >> Subject: RE: Forward record for WWW >> >> ATTENTION: This email came from an external source. Do not open >> attachments or click on links from unknown senders or unexpected emails. >> >> >> Ah, I found it. >> When I query, I get your old serial number, not the new one. >> Perhaps the zone is "stuck" in cache and an rndc reload is not working for >> you? >> You can either stop/restart the server or try rndc flushname and rndc >> reload again. >> >> [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org. >> soa >> >> ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us. >> wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got >> answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa >> rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion >> requested but not available >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;wadsworth.org. IN SOA >> >> ;; ANSWER SECTION: >> wadsworth.org. 86400 IN SOA pauling.wadsworth.org. >> qll.wadsworth.org. 1604120926 10800 3600 604800 86400 >> >> ;; AUTHORITY SECTION: >> wadsworth.org. 86400 IN NS ns1.albany.edu. >> wadsworth.org. 86400 IN NS pauling.wadsworth.org. >> wadsworth.org. 86400 IN NS beacon.health.state.ny.us. >> >> ;; ADDITIONAL SECTION: >> pauling.wadsworth.org. 86400 IN A 199.184.16.6 >> beacon.health.state.ny.us. 10800 IN A 192.135.176.22 >> >> ;; Query time: 68 msec >> ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31 >> GMT 2016 ;; MSG SIZE rcvd: 203 >>
RE: Forward record for WWW
Ralf, All, Sorry, there was a brief side discussion. A couple of years ago we implemented a test server, same platform (in this case cloned virtual systems) with same source tables and config, running in the same environment, in this case my DMZ. Because I didn't want to risk damage to the master, as we have corrupted tables and crashed servers, we implement changes on the test server, and if it works as expected we rsync the updated tables to the live master from the test master. Someone else reported a problem with dig to my server, and I'd thought the list was CC'd, but the test is 199.184.16.7 and is apparently blocked at the FW, as the test master and the actual master both live in the DMZ but the test machine does not normally need to be seen from outside. My - what an extraordinary result! Looking again at the SOA from dig, included below we see 1604xxx, an April date "YYMMHHMMSS". When I looked at dig output again a moment ago, I saw a March date, 1603xxx (yes, I have a script that subs that in when I move the tables from the source to the root directory, complex combo of RCS, followed by # SED as RCS doesn't provide integer revision numbers and an # rsync to the directory read by the daemon, all on my test machine. If that all checks out, an rsync from the test machine live (rather than source) directory to the live directory on the actual master server). In any case, I stopped and started the server, and the A record is now being reported. So, for reasons I don't understand, the SOA as reported by DIG does not match the SOA serial imbedded in the file and reported by the server log. We solved my first problem, but I am now very confused by the apparent cause. I have run the rsync from my test server to my production master, reloaded the tables, reloaded the tables. I see the same SOA as the test server (I rsync the tables with no changes, SOA on my test and production servers is the same), in the named logs, in DIG output, in the source files. Something is a bit hinky with my test server and I've no idea what. If anyone has any suggestions I'd love to hear them, but with your help the issue I was having has been resolved by restarting the server, rather than reloading the zones files. Many thanks, Brian > -Original Message- > From: Bischof, Ralph F. (MSFC-IS40)[NICS] [mailto:ralph.bisc...@nasa.gov] > Sent: Thursday, May 05, 2016 3:03 PM > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov> > Subject: RE: Forward record for WWW > > ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails. > > > Ah, I found it. > When I query, I get your old serial number, not the new one. > Perhaps the zone is "stuck" in cache and an rndc reload is not working for > you? > You can either stop/restart the server or try rndc flushname and rndc > reload again. > > [rbisc...@nsc1.nasa.gov ~]$ dig @beacon.health.state.ny.us. wadsworth.org. > soa > > ; <<>> DiG ALU DNS 6.1 Build 44 <<>> @beacon.health.state.ny.us. > wadsworth.org. soa ; (1 server found) ;; global options: +cmd ;; Got > answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51689 ;; flags: qr aa > rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; WARNING: recursion > requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wadsworth.org. IN SOA > > ;; ANSWER SECTION: > wadsworth.org. 86400 IN SOA pauling.wadsworth.org. > qll.wadsworth.org. 1604120926 10800 3600 604800 86400 > > ;; AUTHORITY SECTION: > wadsworth.org. 86400 IN NS ns1.albany.edu. > wadsworth.org. 86400 IN NS pauling.wadsworth.org. > wadsworth.org. 86400 IN NS beacon.health.state.ny.us. > > ;; ADDITIONAL SECTION: > pauling.wadsworth.org. 86400 IN A 199.184.16.6 > beacon.health.state.ny.us. 10800 IN A 192.135.176.22 > > ;; Query time: 68 msec > ;; SERVER: 192.135.176.22#53(192.135.176.22) ;; WHEN: Thu May 05 19:00:31 > GMT 2016 ;; MSG SIZE rcvd: 203 > > [rbisc...@nsc1.nasa.gov ~]$ > > > Thank you, > Ralph F. Bischof, Jr. > The opinions expressed within this communication are not necessarily those > of NASA. > > > > > -Original Message- > > From: Cuttler, Brian R. (HEALTH) [mailto:brian.cutt...@health.ny.gov] > > Sent: Thursday, May 05, 2016 2:00 PM > > To: Bischof, Ralph F. (MSFC-IS40)[NICS] <ralph.bisc...@nasa.gov> > > Subject: RE: Forward record for WWW > > > > Good suggestions all. > > > > First was a look with # cat, # cat -evt has proven
RE: Forward record for WWW
Barry, > The output shows that there clearly isn't an A record for the zone apex. > You need to post the zone file if you want help with what you did wrong. > My guess is you either forgot the "." at the end of the name, or didn't > reload the server after updating the zone file. Those would have been my guesses also, but I'm unable to resolve wadsworth.org.wadsworth.org which I'd expect to be the result of a missing dot. I'm including the head of the file, it is longer than we really need. Also including the last few lines of the server log file, SOA serial matches the zone file. 12-Apr-2016 09:29:23.221 general: info: reloading zones succeeded 12-Apr-2016 09:29:23.225 general: info: zone wadsworth.org/IN/internal: loaded serial 1604120926 12-Apr-2016 09:29:23.229 general: info: zone wadsworth.org/IN/external: loaded serial 1604120926 05-May-2016 11:27:07.264 general: info: received SIGHUP signal to reload zones 05-May-2016 11:27:07.265 general: info: loading configuration from '/etc/named.conf' 05-May-2016 11:27:07.266 general: info: reading built-in trusted keys from file '/etc/bind.keys' 05-May-2016 11:27:07.267 general: info: using default UDP/IPv4 port range: [1024, 65535] 05-May-2016 11:27:07.267 general: info: using default UDP/IPv6 port range: [1024, 65535] 05-May-2016 11:27:07.274 general: info: sizing zone task pool based on 48 zones 05-May-2016 11:27:07.275 general: warning: Warning: view internal: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones 05-May-2016 11:27:07.280 general: info: reloading configuration succeeded 05-May-2016 11:27:07.281 general: info: reloading zones succeeded 05-May-2016 11:27:07.284 general: info: zone wadsworth.org/IN/internal: loaded serial 1605051125 05-May-2016 11:27:07.287 general: info: zone wadsworth.org/IN/external: loaded serial 1605051125 [root@euclid named]# [euclid]: /etc/dns-root > more db.wadsworth.org $TTL 86400 @ IN SOA pauling.wadsworth.org. qll.wadsworth.org. ( 1605051125 ; serial number 10800 ; refresh after 3 hours 3600; retry after 1 hour 604800 ; expire after 1000 hour 86400 ) ; minimum ttl of 1 day IN NS pauling.wadsworth.org. IN NS ns1.albany.edu. IN NS beacon.health.state.ny.us. pauling.wadsworth.org. IN A 199.184.16.6 ; 27-feb-2007 gatecl1-dmz1IN A 199.184.16.8 gatecl2-dmz1IN A 199.184.16.9 gatecl-dmz1 IN A 199.184.16.10 ;ns1.albany.edu.IN A 169.226.1.100 ;beacon.health.state.ny.us. IN A 192.135.176.22 localhost IN A 127.0.0.1 gate3.wadsworth.org. INA 199.184.16.5 ; 2016-03-24 BRC ; short TTL forward record pointing domain name to WWW IP address. DO NOT USE CN AME, they are ; "cononical" and would screw up the MX records!! ; If no problems we can lengthen the TTL and later remove the record specific va lue. ; Tested with no issues on intra-net DNS servers. wadsworth.org. 300 IN A 199.184.16.22 ; simply not being served, removed until I can figure out why ; 2012-12-10 per ivan wadsworth.org. IN TXT "v=spf1 ptr:wadsworth.org ip4:199.184.28.0/22 ?all" --removing dig output and other already posted information-- Thank you, Brian ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward record for WWW
In article <mailman.731.1462469692.73610.bind-us...@lists.isc.org>, "Cuttler, Brian R. (HEALTH)" <brian.cutt...@health.ny.gov> wrote: > Since this is only a test server not production, and lives in the DMZ it must > be blocked at the FW. > > # dig with no specification for query type and with "A" both give the same > result. Dig with q-type "any" is output included. > > Sorry that prior email had bad line breaks, looked ok when I wrote it but > they have moved us to outlook and I am apparently not sufficient proficient > in its use. The output shows that there clearly isn't an A record for the zone apex. You need to post the zone file if you want help with what you did wrong. My guess is you either forgot the "." at the end of the name, or didn't reload the server after updating the zone file. > > This is the output from dig against this server. > > [euclid] ~ 201> dig @199.184.16.7 wadsworth.org > > ; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wadsworth.org. IN A > > ;; AUTHORITY SECTION: > wadsworth.org. 86400 IN SOA pauling.wadsworth.org. > qll.wadsworth.org. 1603081507 10800 3600 604800 86400 > > ;; Query time: 0 msec > ;; SERVER: 199.184.16.7#53(199.184.16.7) > ;; WHEN: Thu May 05 13:29:15 EDT 2016 > ;; MSG SIZE rcvd: 90 > > > > [euclid] ~ 213> dig any @199.184.16.7 wadsworth.org > > ; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;wadsworth.org. IN ANY > > ;; ANSWER SECTION: > wadsworth.org. 86400 IN MX 10 smtptoo.wadsworth.org. > wadsworth.org. 86400 IN MX 10 smtpproxy.wadsworth.org. > wadsworth.org. 86400 IN MX 5 wish1.wadsworth.org. > wadsworth.org. 86400 IN TXT "v=spf1 ptr:wadsworth.org > ip4:199.184.28.0/22 ?all" > wadsworth.org. 86400 IN SOA pauling.wadsworth.org. > qll.wadsworth.org. 1603081507 10800 3600 604800 86400 > wadsworth.org. 86400 IN NS ns1.albany.edu. > wadsworth.org. 86400 IN NS pauling.wadsworth.org. > wadsworth.org. 86400 IN NS beacon.health.state.ny.us. > > ;; ADDITIONAL SECTION: > wish1.wadsworth.org.86400 IN A 199.184.16.38 > smtptoo.wadsworth.org. 86400 IN A 199.184.16.18 > smtpproxy.wadsworth.org. 86400 IN A 199.184.16.16 > pauling.wadsworth.org. 86400 IN A 199.184.16.6 > > ;; Query time: 0 msec > ;; SERVER: 199.184.16.7#53(199.184.16.7) > ;; WHEN: Thu May 05 13:30:49 EDT 2016 > ;; MSG SIZE rcvd: 369 > > [euclid] ~ 214> > > > -Original Message- > > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > > Sent: Thursday, May 05, 2016 12:12 PM > > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov> > > Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org > > Subject: Re: Forward record for WWW > > > > ATTENTION: This email came from an external source. Do not open > > attachments or click on links from unknown senders or unexpected emails. > > > > > > On Thu, May 05, 2016 at 04:06:06PM +, Cuttler, Brian R. (HEALTH) > > <brian.cutt...@health.ny.gov> wrote a message of 34 lines which said: > > > > > I configured the change for my external test server only > > > (199.184.16.7, which is _probably_ available for external query) > > > > No. > > > > % dig @199.184.16.7 A wadsworth.org > > > > ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1 > > server found) ;; global options: +cmd ;; connection timed out; no servers > > could be reached -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Forward record for WWW
Since this is only a test server not production, and lives in the DMZ it must be blocked at the FW. # dig with no specification for query type and with "A" both give the same result. Dig with q-type "any" is output included. Sorry that prior email had bad line breaks, looked ok when I wrote it but they have moved us to outlook and I am apparently not sufficient proficient in its use. This is the output from dig against this server. [euclid] ~ 201> dig @199.184.16.7 wadsworth.org ; <<>> DiG 9.10.2-P3 <<>> @199.184.16.7 wadsworth.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8047 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wadsworth.org. IN A ;; AUTHORITY SECTION: wadsworth.org. 86400 IN SOA pauling.wadsworth.org. qll.wadsworth.org. 1603081507 10800 3600 604800 86400 ;; Query time: 0 msec ;; SERVER: 199.184.16.7#53(199.184.16.7) ;; WHEN: Thu May 05 13:29:15 EDT 2016 ;; MSG SIZE rcvd: 90 [euclid] ~ 213> dig any @199.184.16.7 wadsworth.org ; <<>> DiG 9.10.2-P3 <<>> any @199.184.16.7 wadsworth.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62021 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;wadsworth.org. IN ANY ;; ANSWER SECTION: wadsworth.org. 86400 IN MX 10 smtptoo.wadsworth.org. wadsworth.org. 86400 IN MX 10 smtpproxy.wadsworth.org. wadsworth.org. 86400 IN MX 5 wish1.wadsworth.org. wadsworth.org. 86400 IN TXT "v=spf1 ptr:wadsworth.org ip4:199.184.28.0/22 ?all" wadsworth.org. 86400 IN SOA pauling.wadsworth.org. qll.wadsworth.org. 1603081507 10800 3600 604800 86400 wadsworth.org. 86400 IN NS ns1.albany.edu. wadsworth.org. 86400 IN NS pauling.wadsworth.org. wadsworth.org. 86400 IN NS beacon.health.state.ny.us. ;; ADDITIONAL SECTION: wish1.wadsworth.org.86400 IN A 199.184.16.38 smtptoo.wadsworth.org. 86400 IN A 199.184.16.18 smtpproxy.wadsworth.org. 86400 IN A 199.184.16.16 pauling.wadsworth.org. 86400 IN A 199.184.16.6 ;; Query time: 0 msec ;; SERVER: 199.184.16.7#53(199.184.16.7) ;; WHEN: Thu May 05 13:30:49 EDT 2016 ;; MSG SIZE rcvd: 369 [euclid] ~ 214> > -Original Message- > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > Sent: Thursday, May 05, 2016 12:12 PM > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov> > Cc: Stephane Bortzmeyer <bortzme...@nic.fr>; bind-users@lists.isc.org > Subject: Re: Forward record for WWW > > ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails. > > > On Thu, May 05, 2016 at 04:06:06PM +, Cuttler, Brian R. (HEALTH) > <brian.cutt...@health.ny.gov> wrote a message of 34 lines which said: > > > I configured the change for my external test server only > > (199.184.16.7, which is _probably_ available for external query) > > No. > > % dig @199.184.16.7 A wadsworth.org > > ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1 > server found) ;; global options: +cmd ;; connection timed out; no servers > could be reached ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward record for WWW
On Thu, May 05, 2016 at 04:06:06PM +, Cuttler, Brian R. (HEALTH)wrote a message of 34 lines which said: > I configured the change for my external test server only > (199.184.16.7, which is _probably_ available for external query) No. % dig @199.184.16.7 A wadsworth.org ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @199.184.16.7 A wadsworth.org ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Forward record for WWW
Forgive me, while the records are fully live on my internal servers, I configured the change for my external test server only (199.184.16.7, which is _probably_ available for external query) but not on the master. We had issues years ago, and implemented a server parallel to the master to vet changes on, so if we lost a zone or crashed the server we could find that out without taking out the actual master. I did check the log files for my test server, there were no errors, the zone file seemed to reload without error and even noted the update in the soa serial number. > -Original Message- > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > Sent: Thursday, May 05, 2016 11:55 AM > To: Cuttler, Brian R. (HEALTH) <brian.cutt...@health.ny.gov> > Cc: bind-users@lists.isc.org > Subject: Re: Forward record for WWW > > ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails. > > > On Thu, May 05, 2016 at 03:42:24PM +, Cuttler, Brian R. (HEALTH) > <brian.cutt...@health.ny.gov> wrote a message of 29 lines which said: > > > External record in the zone file is actually wadsworth.org. 300 IN A > > 199.184.16.22 > > None of the three name servers for wadsworth.org serve this A record. > > It seems the master was *not* reloaded. Did you check its BIND logs to > see? May be the new zone with the A record at the apex was rejected for > some reason. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward record for WWW
On Thu, May 05, 2016 at 03:42:24PM +, Cuttler, Brian R. (HEALTH)wrote a message of 29 lines which said: > External record in the zone file is actually > wadsworth.org. 300 IN A 199.184.16.22 None of the three name servers for wadsworth.org serve this A record. It seems the master was *not* reloaded. Did you check its BIND logs to see? May be the new zone with the A record at the apex was rejected for some reason. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward record for WWW
On 5 May 2016 at 11:55, Stephane Bortzmeyerwrote: > On Thu, May 05, 2016 at 03:42:24PM +, > Cuttler, Brian R. (HEALTH) wrote > a message of 29 lines which said: > > > External record in the zone file is actually > > wadsworth.org. 300 IN A 199.184.16.22 > > None of the three name servers for wadsworth.org serve this A record. > > It seems the master was *not* reloaded. Did you check its BIND logs to > see? May be the new zone with the A record at the apex was rejected > for some reason. > Or perhaps the record was added to a hidden master without the serial number being updated, and so a zone transfer hasn't happened? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue
I think you need to understand that what's in the zone file is of little importance -- what matters is how the data is being sent over the wire (as they say). The consumers of DMARC (mail servers) only care about the data that gets sent to them over the wire. If it's correct over-the-wire, then you can just ignore how the records are represented in the zone file on the master and/or slave. Nothing to see here, move along. Do you have access to some sort of packet capture program (e.g. wireshark/tcpdump/snoop) and at least some rudimentary skills in using such a tool? Such a tool and the knowledge to use it, will serve you well if you intend to progress as a DNS administrator. - Kevin P.S. I trimmed the remainder of the message thread, since you responded to a digest and thus included a bunch of messages which are unrelated to the topic at hand. -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Vaughan Sent: Monday, January 05, 2015 11:04 PM To: 'bind-users@lists.isc.org' Subject: RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue Yes, I have read that part of the FAQ, which concerns people asking whether they need to add escape characters manually in the DMARC record. I do not add these myself. As shown by my examples below, the entry in the master zone is free of any escape characters. However, when an update is triggered, the escape characters are being added to the entry on the slave zone automatically. Why is this happening and how do I stop it? Chris Vaughan | Communications Officer, ICT Land and Property Information | Level 5, 1 Prince Albert Road Queens Square NSW 2000 e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DMARC Record issue
On 2015-01-04 19:30, Chris Vaughan wrote: I have been given the task of implementing DMARC in our BIND servers due the recommendation of a security audit on our systems. Whenever I create the record in the forward server, and refresh the zone, it comes out in the slave zone with escape characters inserted in the TXT record. This occurs in every version of BIND that I have tried, from 9.7 up to 9.10. Primary test zone record: _dmarc.domain. IN TXT v=DMARC1; p=reject; rua=root@dns-test-1.domain; aspf=s; rf=afrf; sp=reject Slave test zone record: _dmarc TXT v=DMARC1\; p=reject\; rua=root@dns-test-1.domain\; aspf=s\; rf=afrf\; sp=reject http://www.dmarc.org/faq.html#s_12 has some information on what is happening here. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DMARC Record issue
Dave Warren da...@hireahit.com wrote: http://www.dmarc.org/faq.html#s_12 has some information on what is happening here. There is a fix for this which will be in the next 9.9 and 9.10 versions of BIND. https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=9a36fb86f5019f25705d25ea729d03fcf8ecaa95 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dover, Wight, Portland, Plymouth: South 5 or 6, veering southwest 6 to gale 8, becoming cyclonic 4 or 5 later. Moderate or rough, occasionally very rough in Portland and Plymouth. Rain. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: bind-users Digest, Vol 2012, Issue 1: Re: DMARC Record issue
Yes, I have read that part of the FAQ, which concerns people asking whether they need to add escape characters manually in the DMARC record. I do not add these myself. As shown by my examples below, the entry in the master zone is free of any escape characters. However, when an update is triggered, the escape characters are being added to the entry on the slave zone automatically. Why is this happening and how do I stop it? Chris Vaughan | Communications Officer, ICT Land and Property Information | Level 5, 1 Prince Albert Road Queens Square NSW 2000 e: chris.vaug...@lpi.nsw.gov.au | t: 02 92286884 | m: 0401 148061 | f: 02 92231271 | http://www.services.nsw.gov.au I http://www.lpi.nsw.gov.au -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of bind-users-requ...@lists.isc.org Sent: Monday, 5 January 2015 11:00 PM To: bind-users@lists.isc.org Subject: bind-users Digest, Vol 2012, Issue 1 Send bind-users mailing list submissions to bind-users@lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than Re: Contents of bind-users digest... Today's Topics: 1. Re: BIND DNSSEC Guide draft (Timothe Litt) 2. DMARC Record issue (Chris Vaughan) 3. Re: DMARC Record issue (Dave Warren) 4. Re: Unable to get for www.revk.uk from some of our servers (Phil Mayers) -- Message: 1 Date: Sun, 04 Jan 2015 16:13:40 -0500 From: Timothe Litt l...@acm.org To: jr...@isc.org Cc: bind-users@lists.isc.org Subject: Re: BIND DNSSEC Guide draft Message-ID: 54a9ad04.6010...@acm.org Content-Type: text/plain; charset=windows-1252 On 31-Dec-14 21:00, Jeremy C. Reed wrote: ISC is seeking feedback and review for our first public draft of the BIND DNSSEC Guide. It was written in collaboration with DeepDive Networking. I haven't had a chance to look in detail, but a quick scan resulted in several observations that I hope are useful. Also, I posted your note to dnssec-deployment, where there should be enthusiasm for the topic :-) The private network section 6.5.4 doesn't talk about how to configure views/stub zones so that authoritative (internal) zones on a shared resolver/authoritative server get validated. (point 1 in the section dismisses the possibility.) This can be done. Further, it's useful. People are much more likely to experiment on internal zones. More important, consider a typical scenario: my web server on the internal view has a different address from the external view. (Besides efficiency, some commercial routers don't do NAT on a stick - e.g. allow an internal client to NAT to an external address served by that router, which is NATed to an internal server.) So we want to train users to look for DNSSEC authentication. Unless one makes this work, a notebook on the road will authenticate, but the same notebook in the office will not. Don't bother trying to explain this to users; they'll simply ignore the distinction. Which is sort of a long way of saying: if the goal is to encourage people to adopt DNSSEC, your guide should make Private Networks and the corresponding recipes first class citizens, not a 'don't bother with this' afterthought. Both for admins to feel freer to experiment, and for users to have a consistent experience. On key rollover - this is still a major hassle. And while the recipes look pretty, the process is ugly. Key rollover really needs to be automated. There are too many steps that require too much indirection. And too many 'you could do this or you could do that' choices - that don't really matter, especially for getting started. I don't see why a person should have to change parameters, dates, manually generate keys, etc. You can work on the recipes, but I don't think they'll make the problem approachable - or safe. Computers are good at this stuff - and people aren't. It really needs something like a daily cron job with a simple config file that does all the work. Trigger based on dates, or a 'do it now' emergency/manual command. Key generation, date setting, permissions, etc. As for key uploads to external registrars, it can mail the new keys/DS records to the admin with 'please upload these by 'date'', and only proceed with the roll-over when it can 'dig' them. (The e-mail can - via the config file - include a hyperlink to the upload page...) For internal, it can update the trusted keys include file, rndc reconfig, etc. And the config file should come with reasonable default parameters, so it 'just works' oob. E.g. roll the zsks
Re: DANE record rejected by named-checkzone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/2014 11:54 PM, Mark Andrews wrote: In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman writes: named keeps refusing my zone file in which I included a DANE record: [root]# named-checkzone offerman.com db.offerman.com db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names) zone offerman.com/IN: loaded serial 2014110103 OK [root]# This appears to be caused by the underscores used in the port/protocol combination. Here's what the record looks like: _443._tcp IN TLSA3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce Well that isn't a valid TLSA record. It has a bad hex encoding. There are 63 hex digits. Just an error in the cutting/pasting, in the mail message that is. TLSA records themselves are not subject to check-names processing so I suggest that you look at the reported lines in the file to find out what is actually there. In the example below it is the A record which has inherited the _443._tcp owner name. Ah, that did the job! :-) Inserting a block of TLSA records at the wrong place screwed up the inheritance for the next record. Thanks! Adrian Mark [rock:~/git/bind9] marka% bin/check/named-checkzone c.db c.db c.db:1: no TTL specified; using SOA MINTTL instead dns_rdata_fromtext: c.db:3: near eol: bad hex encoding c.db:4: _443._tcp.c.db: bad owner name (check-names) zone c.db/IN: loading from master file c.db failed: bad hex encoding zone c.db/IN: not loaded due to errors. [rock:~/git/bind9] marka% @IN SOA . . 0 0 0 0 0 @ IN NS . _443._tcp IN TLSA 3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce IN A 1.2.3.4 It was created first using this: tlsa --create --output rfc offerman.com later using this: ldns-dane create offerman.com 443 both resulting in the same record, and both outputs resulting in the same error. I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6, but all to no avail :-( [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6 Am I trying to do something here that is not yet supported or am I overlooking something? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUe0v1AAoJECfzYtonqXzEKHgIAJyjwFIgXbZ1eO01eR8JO4Au s51DVqywT7/0nVfF55Zi6N8mOi9GygYJjSEFJ4lL6g2BI2TaNVzeAQqGp9oJ8UUf GzJOjLkb7UyPy5OXYjkIj4a2f7t8Eyk7kRXYhfDaPccox87R8NkIWkCftSrfgBEq LwwTlHrtf2QUi5QxzhsNP/ljuC5mF0EW2ipa3kEggTgHwQ3Sg9pSvxWwP8LVFRn4 RW1ng/9iALxrgQLS7qjEc29vTfj0emRskQEXOgS/Ipt0U9b2Ep5l8uHsULH0jNwP BJ5+QPJFETlHd6hqKNjpAsVBrZJ+fY4QgIC8Ig8nkWY4gBLtZ55qkb6zIbOFL4Y= =YVKh -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DANE record rejected by named-checkzone
In message 545954b0.8080...@offerman.com, Adrian (Aad) Offerman writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 named keeps refusing my zone file in which I included a DANE record: [root]# named-checkzone offerman.com db.offerman.com db.offerman.com:59: _443._tcp.offerman.com: bad owner name (check-names) db.offerman.com:60: _443._tcp.offerman.com: bad owner name (check-names) zone offerman.com/IN: loaded serial 2014110103 OK [root]# This appears to be caused by the underscores used in the port/protocol combination. Here's what the record looks like: _443._tcp IN TLSA3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce Well that isn't a valid TLSA record. It has a bad hex encoding. There are 63 hex digits. TLSA records themselves are not subject to check-names processing so I suggest that you look at the reported lines in the file to find out what is actually there. In the example below it is the A record which has inherited the _443._tcp owner name. Mark [rock:~/git/bind9] marka% bin/check/named-checkzone c.db c.db c.db:1: no TTL specified; using SOA MINTTL instead dns_rdata_fromtext: c.db:3: near eol: bad hex encoding c.db:4: _443._tcp.c.db: bad owner name (check-names) zone c.db/IN: loading from master file c.db failed: bad hex encoding zone c.db/IN: not loaded due to errors. [rock:~/git/bind9] marka% @ IN SOA . . 0 0 0 0 0 @ IN NS . _443._tcp IN TLSA 3 0 1 a66939453856cd6b0f78427eb38d3a9921cfb8bab928d24017a172647e323ce IN A 1.2.3.4 It was created first using this: tlsa --create --output rfc offerman.com later using this: ldns-dane create offerman.com 443 both resulting in the same record, and both outputs resulting in the same error. I've upgraded the named version (on CentOS 6.6) from 9.8.2 to 9.9.6, but all to no avail :-( [root]# named-checkzone -v 9.9.6-RedHat-9.9.6-0.el6 Am I trying to do something here that is not yet supported or am I overlooking something? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWVSwAAoJECfzYtonqXzEdIsIAIiHdjp726NW57jF6lxF7cFc oFNFx8uClGHveq6nWjzG9DhplEkFjl8UYMJyfKx3MUlgnKGerREI13WyEwmOrIvk TigcjVEwb3AnbX7RGtzeyqsSAJesx8JdYgLxpSTltfeNpYwjJ4Irl1YQKw3e6hHY y8Lcd9gOYYj+weyZv8BoaEIugit/fuxiLOyJ7mqhyHmrDlny1FLbHMOAJzU8WBxx aa3IUT91RYP5037d4k3Klk+XbieFoiAGSnvHiaqfg8SuXiosiEKAZOfxymb04sqd a4rDiLv6RkLGR8UIWuNfiXNTyGvcZZeW9micMIHVXk/EeEJ1Y7W6vdbwBDJ8M2s= =CVi6 -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 11.09.14 13:14, Bob Harold wrote: In reference to the question of using a CNAME or A record for www.example.com, it seems to me that the best solution, if we could ever get there, would be to create a new record type that means redirect an A or lookup to this other name. Like this: example.com. IN SOA example.com. IN ANAME my.webhosting.com. www.example.com. IN CNAME my.webhosting.com. I use ANAME to mean like a CNAME, but only for A and lookups, with no restrictions on other names with the same left side (except perhaps other A and records if that is necessary for technical reasons). Several DNS and hosting providers provide similar functionality, but is there any chance of widespread DNS support for something like this? It's a server-side thing. The current protocol does not support redirecting only for A and/or , nor any particular types, only everything (CNAME). Is there already and RFC for this? I'm not sure whether this kind of RR should be introduced. Maybe redirect that defines types to be redirected... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. The same applies for all other RRs for exmaple.com Alan named crap. And that's why I also think it's better to define 'www' as A record, not as CNAME -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote: If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. Actually no. All other RRs are supposed to be ignored (except for RRSIG, etc) once the CNAME exists. Ie. the MX and NS RRs exist only for example.com, but not www.example.com. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In article mailman.892.1410364699.26362.bind-us...@lists.isc.org, Alan Clegg a...@clegg.com wrote: On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. Keeping track of one extra A record (and associated record if you go in that direction) isn't a bad thing. And the discussion went on from there. Sorry, I really didn't mean to poke a hornets' nest. (Personal preferences, of course) Personal preference and dependent on the exact needs of the users of the data, of course. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In article mailman.902.1410422525.26362.bind-us...@lists.isc.org, Antonio Querubin t...@lavanauts.org wrote: On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote: If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. Actually no. All other RRs are supposed to be ignored (except for RRSIG, etc) once the CNAME exists. Ie. the MX and NS RRs exist only for example.com, but not www.example.com. I think that's a misunderstanding of what Matus wrote. With separate A records then www.example.com will only have an A record. If you alias www to @ then looking up MX and NS records for www will return the ones for example.com. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. If you make www a CNAME to apex, then the RFCs are clear that you can't point the PTR to the www name. The *only*legal*choice* is to point the PTR at the apex name. You're going to get *much*more* consistent results. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what best practices are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. So, is it better that mail sent erroneously to www.example.com fall through the RFC 5321 algorithm and attempt to be delivered to the A record? That host is almost certainly is a *web* server and quite likely to not even be listening on port 25. After some period of time, the user ultimately gets a connection timed out, still retrying NDR and scratches their head trying to figure out what went wrong. Meanwhile, the sending MTA keeps on retrying, web server sees garbage traffic on an off-port and generates ICMP packets back to the source. In the CNAME to @ scenario, at least the mail gets rejected promptly by a *mail* server, you have a nice clear audit trail on the server side and a meaningful error message (e.g. I don't accept mail for the www.example.com domain) back to the user. (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote no mail service offered here. That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the no service MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). Obviously, if one wants mail for example.com and www.example.com to be delivered to *different* MX targets, then CNAME to @ isn't an option. But in the general case, where you don't want mail to www.example.com to be deliverable *at*all*, CNAME to @ is quite a viable option; arguably, a *better* option, since the failure mode is faster and cleaner than directing MTAs to try to deliver mail, as per RFC 5321, to a web server. The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? What other RR types do you have in mind? SRV records? They have their own defined naming structure, which effectively precludes apex naming. TXT records used for SPF purposes? Worst case for that is that the same hosts trusted to send mail for example.com are also trusted to send mail for www.example.com -- but *sending* mail servers are presumably under the control (directly or indirectly) of the domain owner, so the potential for negative fallout seems rather minimal. Something else? Are you thinking that a LOC record should be differentiated between www and apex, if the web server is physically in a different datacenter than the corporate headquarters of the domain owner? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the first record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the first record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) Last time I checked, ALL matching records are returned as a single Resource Record Set - (and in the case of DNSSEC - covered with a single signature). What the receiver does with it is up to that receiver... as you say - some of the information may be discarded. So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. I would still disagree. When there is forward--reverse checking, one may need the complete answer. I certainly have some processes that do an exhaustive check. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. On 11.09.14 11:20, Kevin Darcy wrote: The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. sorry, but again - you are searching for consistency somewhere, where no consistency (nor a PTR) is required. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what best practices are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. I haven't met a case where this level of consistency would be needed. I have met a case where the only one A should point to an IP caused troubles. your argument fails immediately when there's need for more than just A on www.example.com (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote no mail service offered here. That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the no service MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). ... and this is just example of it. The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? well, me and Alan have shown examples why www CNAME @ is not a good idea. we both also said it's personal preference. What other RR types do you have in mind? Does it matter at all? It _may_ happen, and it's the case where CNAME is not usable. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote: On 9/11/2014 3:47 AM, Matus UHLAR - fantomas wrote: On 10.09.14 18:13, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Completely your decision. Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Do not mix multiple A and PTR. they are just different things. You are creating issues where there are none. On 11.09.14 11:20, Kevin Darcy wrote: The issue is consistency. If you give admins choices where to point a PTR, and the RFCs don't provide any clear guidance, you're going to get inconsistent results. sorry, but again - you are searching for consistency somewhere, where no consistency (nor a PTR) is required. Consistency is a good thing, isn't it? Sure, the earth isn't going to fall off its axis of rotation just because of the way people point their A and PTR records, CNAME or don't CNAME. But if we can nudge people in the direction of consistency, and there is no downside, why wouldn't we do that? That's what best practices are all about -- impelling people towards processes/methods/conventions that ultimately benefit *everyone*. Greatest good for the greatest number, and all that. I haven't met a case where this level of consistency would be needed. Needed? Is that where you're setting the bar here? A little too high, I'd say. My point is that consistency is a good thing, and the CNAME to @ practice helps to foster that. Whether it's *needed* would be a whole other question. Somewhere between necessary and (what Alan called) preferences are these things called recommendations or best practices. I have met a case where the only one A should point to an IP caused troubles. Well, sure. Some names, such as zone-apex names, *cannot* own CNAME records. If example1.com and example2.com need to resolve to the same IP, then, and assuming they are both zone-apex names, you're going to have multiple As with the same RDATA, and a reverse-record ambiguity. That's unavoidable. All I'm saying, is that in the normal case, where you have an option, CNAME to @ makes a lot of sense and should be followed. your argument fails immediately when there's need for more than just A on www.example.com If the RDATA needs to be *different* between www and apex, or the application/subsystem which accesses the resource makes a distinction between canonical names and aliases, sure. I'm not laying down a hard-and-fast rule. Of course there will be exceptions, where the higher-level protocols or the user requirements demand it. (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote no mail service offered here. That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the no service MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). ... and this is just example of it. An example of what? Of what bad things can happen when (semi-)important things are left to mere preference? The same applies for all other RRs for exmaple.com Alan named crap. Actually, the only other RR type that Alan enumerated specifically was NS, which operates on entirely different principles, and serves a significantly different function, than MX-based mail routing. Who would be looking up www.example.com with QTYPE=NS? Is that even a plausible use-case scenario? well, me and Alan have shown examples why www CNAME @ is not a good idea. Alan's concern was that the www name could get associated with record types that the DNS admin might not have expected. This is not a problem for a competent admin, who will have realistic expectations and an understanding of CNAME mechanics. You raised the possibility that a mail server might reject messages sent erroneously to www and I responded that if it's going to fail anyway, at least that failure mode is better than a mail server trying to deliver mail to a web server (which is what happens in the same scenario when www is an independent A record). You got anything else? we both also said it's personal preference. And I'm saying that's a cop-out. It should be a recommended practice -- except where there are special mitigating circumstances which make it inappropriate or unworkable -- not merely a preference. Hair styles and musical genres are preferences; encouraging consistent forward/reverse mappings is something that all DNS admins have a stake in, whether they realize it or not. What other RR types do you have in mind? Does it matter at all? It _may_ happen, and it's the case
Re: A record of domain name must be name server ?
On 9/11/2014 12:08 PM, Matus UHLAR - fantomas wrote: we both also said it's personal preference. On 11.09.14 12:53, Kevin Darcy wrote: And I'm saying that's a cop-out. It should be a recommended practice encouraging consistent forward/reverse mappings is something that all DNS admins have a stake in, whether they realize it or not. correct reverse-forward mappings - yes. correct forward-reverse mappings - no. In zones apexes it's sometimes just impossible and I have already met people uselessly insisting on such (pardon me) shit without understanding real (and potentially much bigger) problem. It's not usable where it's not usable, of course. But, where it *is* usable, I'm just saying it's recommended, It's definitely not recommended by me. You are of course free to recommend what you choose, but I think I should warn you I'll oppose that... Did you seriously think I'd recommend something that *doesn't*work*? Please, give me a little more credit than that. I remember you from your postings here, so I really don't think you are incompetent, especially not an idiot :-) I just don't agree with this point, because I have already met people not getting this properly and insisting on something that was likely to get them into troubles bigger than with having multiple A's... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck Porky Pig ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In reference to the question of using a CNAME or A record for www.example.com, it seems to me that the best solution, if we could ever get there, would be to create a new record type that means redirect an A or lookup to this other name. Like this: example.com. IN SOA example.com. IN ANAME my.webhosting.com. www.example.com. IN CNAME my.webhosting.com. I use ANAME to mean like a CNAME, but only for A and lookups, with no restrictions on other names with the same left side (except perhaps other A and records if that is necessary for technical reasons). Several DNS and hosting providers provide similar functionality, but is there any chance of widespread DNS support for something like this? Is there already and RFC for this? I find these interesting sites: http://www.dnsmadeeasy.com/services/aname-records/ http://aws.amazon.com/route53/faqs/#Supported_DNS_record_types http://blog.andrewallen.co.uk/2012/06/27/cname-is-out-hello-aname/ (This last one points out a problem with the current implementations - I think proper support in the DNS protocol would solve this.) -- Bob Harold DNS and DHCP University of Michigan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/11/2014 11:51 AM, Mark Elkins wrote: On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the first record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) Last time I checked, ALL matching records are returned as a single Resource Record Set - (and in the case of DNSSEC - covered with a single signature). What the receiver does with it is up to that receiver... as you say - some of the information may be discarded. If the invoker is using the classic gethostbyaddr() interface, then it'll only see the RDATA from the first PTR RR, where first is determined by the local nameserver implementation and/or the local Operating System interface for name resolution. So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. I would still disagree. When there is forward--reverse checking, one may need the complete answer. I certainly have some processes that do an exhaustive check. Certainly if one gets down to the resolver-library level and grovels through all of the RRs in the Answer Section of the response packet, one could certainly care more than the typical reverse-resolving app/subsystem would. And any software that builds up certain heightened expectations is likely to complain if those expectations are not met. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/11/2014 11:51 AM, Mark Elkins wrote: On Thu, 2014-09-11 at 11:27 -0400, Kevin Darcy wrote: Mark, Depending on implementation, a PTR RRset with multiple records either -- only ever gets answered with the first record of the set (in which case the second and subsequent records of the set are just a waste of space), or -- answers in a random, cyclic and/or round-robin fashion (in which case, the results are non-deterministic from the standpoint of a client, and this can cause problems and/or confusion) Last time I checked, ALL matching records are returned as a single Resource Record Set - (and in the case of DNSSEC - covered with a single signature). What the receiver does with it is up to that receiver... as you say - some of the information may be discarded. If the invoker is using the classic gethostbyaddr() interface, then it'll only see the RDATA from the first PTR RR, where first is determined by the local nameserver implementation and/or the local Operating System interface for name resolution. So, although the standards allow multiple RRs, in practical terms, it only makes sense for a PTR RRset to contain a *single* RR. I would still disagree. When there is forward--reverse checking, one may need the complete answer. I certainly have some processes that do an exhaustive check. Certainly if one gets down to the resolver-library level and grovels through all of the RRs in the Answer Section of the response packet, one could certainly care more than the typical reverse-resolving app/subsystem would. And any software that builds up certain heightened expectations is likely to complain if those expectations are not met. - Kevin On 9/11/2014 3:45 AM, Mark Elkins wrote: On Wed, 2014-09-10 at 18:13 -0400, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. Although I prefer the use of a CNAME solution (CNAME www.example.com to example.com), in the case of separate A (and ) records, one could point the reverse to both names. Nothing wrong with a PTR record having more than one answer. There is then no inconsistency, just choice. After all, pretty much every NS record has at least two Right-Hand-Sides (Answers) If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin Well, this is certainly getting far away from an answer to the original qustion! Originally our web server was only available as www.adi.com. Later I noticed that a lot of sites were available without the www. So I decided to allow our web server to be available as adi.com. But I still consider www.adi.com to be the real name of the server. And I certainly can not alias adi.com to www.adi.com! Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In message 5411bdd6.4010...@chrysler.com, Kevin Darcy writes: (Yes, I'm aware that there was a proposal recently discussed on the DNSOP list for an MX-target convention to denote no mail service offered here. That would presumably solve the problem I cited in the previous paragraph. But AFAIK that proposal is many years away from widespread adoption, and even if adopted, it puts an extra burden on the DNS admins to populate the no service MX record, which, again, is going to produce inconsistent results -- some admins will remember to do it; many won't). No, it's more like formalising existing practice. Universal adoption would be a long time off but there is a large existing base of MTA's that will do the right thing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Hi, xxx.com and IP address 192.168.1.100 is just a example domain name and IP address. Our boss want everybody access our domain example.com through browser, then it will redirect to our web site www.example.com. So I want to get more information about unexpected impact when we changed DNS records. Thanks for your help. Best Regards, Pete Fong Here is how I have things set up here. Our domain is adi.com. We have three name servers set up. Our web site can be accessed as both www.adi.com and adi.com. Here is what I have on our zone file: @ in ns bluegill.adi.com. in ns a.dns.tds.net. in ns seahorse.adi.com. bluegillin A 75.100.245.131 seahorsein A 75.100.245.134 www in A 75.100.245.133 @ in A 75.100.245.133 @ in mx 0 mackerel.adi.com. in mx 10 seahorse.adi.com. in mx 20 bluegill.adi.com. Note that address 75.100.245.133 is entered twice. The mx records are to get email to work correctly. Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In article mailman.890.1410357943.26362.bind-us...@lists.isc.org, sch...@adi.com (Thomas Schulz) wrote: Hi, xxx.com and IP address 192.168.1.100 is just a example domain name and IP address. Our boss want everybody access our domain example.com through browser, then it will redirect to our web site www.example.com. So I want to get more information about unexpected impact when we changed DNS records. Thanks for your help. Best Regards, Pete Fong Here is how I have things set up here. Our domain is adi.com. We have three name servers set up. Our web site can be accessed as both www.adi.com and adi.com. Here is what I have on our zone file: @ in ns bluegill.adi.com. in ns a.dns.tds.net. in ns seahorse.adi.com. bluegillin A 75.100.245.131 seahorsein A 75.100.245.134 www in A 75.100.245.133 @ in A 75.100.245.133 @ in mx 0 mackerel.adi.com. in mx 10 seahorse.adi.com. in mx 20 bluegill.adi.com. Note that address 75.100.245.133 is entered twice. The mx records are to get email to work correctly. And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ Though in Thomas' case the PTR record for 75.100.245.133 returns www.adi.com, so that's a good reason for not doing the CNAME thing. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. Keeping track of one extra A record (and associated record if you go in that direction) isn't a bad thing. (Personal preferences, of course) AlanC signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ On 10.09.14 08:58, Alan Clegg wrote: And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. Keeping track of one extra A record (and associated record if you go in that direction) isn't a bad thing. simply said: don't CNAME to @. (Personal preferences, of course) yes, but still... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/10/2014 11:58 AM, Alan Clegg wrote: On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. And why is that a _bad_ thing? If I ever change that IP, I want to change it in *one*place*. The CNAME allows everything to automatically follow that change. Why necessitate multiple updates when a single update will do? If TTL-manipulation is necessary in order to minimize caching complications, the number of RRset updates is magnified, of course. MXes and NSes are a non-issue, IMO, since the contexts in which people look up a www name (usually end-users trying to access a website) are usually quite disjoint from the use cases of MXes (automated systems delivering mail) or NSes (nameserver-to-nameserver traffic). I see little or no risk of confusion or misdirection. I suppose it's _possible_ that some day a mail sender might mistype a recipient as u...@www.example.com instead of (as they should have) u...@example.com, and maybe in that scenario the CNAME will cause the recipient address to show up in the headers of the received message in an unexpected way. But, to me, this falls under the generic category of GIGO (garbage in, garbage out) -- you type something wrong into a computer system, you might not get the results you expected... - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/10/14, 2:13 PM, Kevin Darcy wrote: On 9/10/2014 11:58 AM, Alan Clegg wrote: On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. And why is that a _bad_ thing? (Personal preferences, of course) Answered before asked. AlanC signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 9/10/2014 5:20 PM, Alan Clegg wrote: On 9/10/14, 2:13 PM, Kevin Darcy wrote: On 9/10/2014 11:58 AM, Alan Clegg wrote: On 9/10/14, 8:42 AM, Sam Wilson wrote: And you could reduce maintenance very slightly by replacing www in A 75.100.245.133 with www in CNAME @ And now you have an MX record, 3 NS records and a bunch of other crap associated with the WWW address. And why is that a _bad_ thing? (Personal preferences, of course) Answered before asked. Well, I was asking about your _particular_ preference, which seemed rather clear from your use of the word crap. Why does it matter (in _your_ opinion) if the target of the www CNAME owns records of more types than just A and/or ? Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin On 9/10/2014 5:48 PM, Eliezer Croitoru wrote: Hey Kevin, This is not an issue at all. A PTR is different then a A record and can be used by two reverse domain names and only the owner of the IP addresses space can define them. I am not sure if two PTR records for two domains will be applied to one IP but it is possible for two IP addresses to have the same PTR. Can we even use a CNAME as a PTR??? Eliezer On 09/11/2014 12:37 AM, Kevin Darcy wrote: Also, have you considered the forward/reverse ambiguity that arises when multiple owner names resolve to the same address? To which of those names does the PTR point? - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Well this is a confusing point but it's rather an administrative decision to make. If indeed the network\server\domain administrator is not aware of his services he will either have or will not have decision to make. It will depend on whether he knows what he is doing. Mish-mosh or banana he will eat it one way or another. One conclusion he will probably learn is that dns records takes from 24 to about 48 hours to be forgotten from dns caches :D All The Bests, Eliezer On 09/11/2014 01:13 AM, Kevin Darcy wrote: No, what I'm saying is that if example.com owns an A record 203.0.113.48, and www.example.com owns an A record 203.0.113.48, then where does 48.113.0.203.in-addr.arpa point? Some people will point it at example.com, some will point it at www.example.com. What you get is a mish-mosh. No consistency. If, on the other hand, www.example.com is a CNAME to example.com, then it's crystal clear where the reverse record will point -- example.com. There is no ambiguity or option for inconsistency. - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Hi Kevin, Thanks for your help. Do not worry. The IP address 192.168.1.100 is just for example. Best Regards, Pete Fong 2014-09-09 3:30 GMT+08:00 Kevin Darcy k...@chrysler.com: Based on the zone contents below, you shouldn't have any problem changing the 192.168.1.100 address to anything you want. But, of course, the zone is illegal because it only has 1 NS record published at the apex (there is a strict minimum of at least 2), and, as it stands now, if it is an Internet-facing zone, it's also illegal due to the presence of a private (192.168.*.*) address in the zone. You said that 192.168.1.100 is our one of DNS server, but hopefully you don't mean that it's a nameserver for *this* zone, or that the zone is not Internet-facing, or the 192.168.1.100 address is presented in a NAT (network address translated) form to the Internet, since, again, you can't use private addresses on the Internet. By definition. - Kevin On 9/8/2014 3:43 AM, Pete Fong wrote: Hi Everybody, The below item is our DNS (BIND) server configuration. our Domain* xxx.com http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? Because we want anybody access our domain *xxx.com http://xxx.com* with internet browser then it will go to our webpage. Am I correct ? I really appreciate anybody help. @ IN SOA ns1.xxx.com. root.ns1.xxx.com ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1.xxx.com. IN A 192.168.1.100 Thank and Best Regards, Pete Fong ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing listbind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Hi, xxx.com and IP address 192.168.1.100 is just a example domain name and IP address. Our boss want everybody access our domain example.com through browser, then it will redirect to our web site www.example.com. So I want to get more information about unexpected impact when we changed DNS records. Thanks for your help. Best Regards, Pete Fong 2014-09-08 20:02 GMT+08:00 /dev/rob0 r...@gmx.co.uk: On Mon, Sep 08, 2014 at 03:43:22PM +0800, Pete Fong wrote: The below item is our DNS (BIND) server configuration. our Domain* xxx.com I think that is a porn site. If you mean to use that name as an example, please use example.com instead. Putting HTTP links to pornography in your emails is a sure way to fall afoul of various content filtering solutions which are in common use. See RFC 2606 regarding reserved domain names like example.com. http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? Because we want anybody access our domain *xxx.com http://xxx.com* with internet browser then it will go to our webpage. Am I correct ? I really appreciate anybody help. It's not unusual to point an A record for @ at a HTTP server. Whatever you are not understanding here, I can't tell. @ IN SOA ns1.xxx.com. root.ns1.xxx.com ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1.xxx.com. IN A 192.168.1.100 This zone file would fail named-checkzone(8) testing if loaded as xxx.com, because there is no A record for the NS name, ns1.xxx.com. This zone would fail to load. If any of your NS names are inside the zone, you must have either or both A and records for those NS names. Here is the same zone without the XXX and with all relative names: @ IN SOA ns1 root.ns1 ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1 IN A 192.168.1.100 ns1 IN A 192.168.1.100 -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On 08.09.14 15:43, Pete Fong wrote: Subject: A record of domain name must be name server ? no. The below item is our DNS (BIND) server configuration. our Domain* xxx.com http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? yes. ... it's completely irelevant where does example.com A record point to. It could only issue a problem if you pointed example.com. NS example.com. or similar MX etc recods. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Hi Matus UHLAR - fantomas, Sorry, I do not understand the meaning of It could only issue a problem if you pointed example.com. NS example.com. or similar MX etc records. Do you mind to explain more details ? Thank you very much. Best Regards, Pete Fong 2014-09-08 16:06 GMT+08:00 Matus UHLAR - fantomas uh...@fantomas.sk: On 08.09.14 15:43, Pete Fong wrote: Subject: A record of domain name must be name server ? no. The below item is our DNS (BIND) server configuration. our Domain* xxx.com http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? yes. ... it's completely irelevant where does example.com A record point to. It could only issue a problem if you pointed example.com. NS example.com . or similar MX etc recods. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good. __ _ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
In article mailman.871.1410167955.26362.bind-us...@lists.isc.org, Pete Fong petefong2...@gmail.com wrote: Hi Matus UHLAR - fantomas, Sorry, I do not understand the meaning of It could only issue a problem if you pointed example.com. NS example.com. or similar MX etc records. Do you mind to explain more details ? Thank you very much. NS records tell everyone where the DNS servers for the domain are. So xxx.com only has to be assigned the IP of the DNS server if you have an NS record that says that xxx.com is the DNS server for xxx.com. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
On Mon, Sep 08, 2014 at 03:43:22PM +0800, Pete Fong wrote: The below item is our DNS (BIND) server configuration. our Domain* xxx.com I think that is a porn site. If you mean to use that name as an example, please use example.com instead. Putting HTTP links to pornography in your emails is a sure way to fall afoul of various content filtering solutions which are in common use. See RFC 2606 regarding reserved domain names like example.com. http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? Because we want anybody access our domain *xxx.com http://xxx.com* with internet browser then it will go to our webpage. Am I correct ? I really appreciate anybody help. It's not unusual to point an A record for @ at a HTTP server. Whatever you are not understanding here, I can't tell. @ IN SOA ns1.xxx.com. root.ns1.xxx.com ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1.xxx.com. IN A 192.168.1.100 This zone file would fail named-checkzone(8) testing if loaded as xxx.com, because there is no A record for the NS name, ns1.xxx.com. This zone would fail to load. If any of your NS names are inside the zone, you must have either or both A and records for those NS names. Here is the same zone without the XXX and with all relative names: @ IN SOA ns1 root.ns1 ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1 IN A 192.168.1.100 ns1 IN A 192.168.1.100 -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A record of domain name must be name server ?
Based on the zone contents below, you shouldn't have any problem changing the 192.168.1.100 address to anything you want. But, of course, the zone is illegal because it only has 1 NS record published at the apex (there is a strict minimum of at least 2), and, as it stands now, if it is an Internet-facing zone, it's also illegal due to the presence of a private (192.168.*.*) address in the zone. You said that 192.168.1.100 is our one of DNS server, but hopefully you don't mean that it's a nameserver for *this* zone, or that the zone is not Internet-facing, or the 192.168.1.100 address is presented in a NAT (network address translated) form to the Internet, since, again, you can't use private addresses on the Internet. By definition. - Kevin On 9/8/2014 3:43 AM, Pete Fong wrote: Hi Everybody, The below item is our DNS (BIND) server configuration. our Domain*xxx.com http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? Because we want anybody access our domain *xxx.com http://xxx.com* with internet browser then it will go to our webpage. Am I correct ? I really appreciate anybody help. @ IN SOA ns1.xxx.com http://ns1.xxx.com. root.ns1.xxx.com http://root.ns1.xxx.com ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1.xxx.com http://ns1.xxx.com. IN A 192.168.1.100 Thank and Best Regards, Pete Fong ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: PTR Record Issue
In message 525f4eea.5060...@cd.kcfam.net, Casey Daniels writes: Hello, I hope this is the right place to ask this question, if not maybe someone could point me in the right direction. I'm using Bind 9.9.3-P2 and have the following issue when ever I run host ::1I always get 1.0.0..ip6.arpa has no PTR Record. I'm pretty sure I have everything straight because if I were to type host ::2 I get an a plain old doesn't exist message. And for the fun of it I added a record of 2.0.0.0.0.0.0 and then hosting ::2 gives me an the expected answer. Presumably you have 'zone 1.0.0.0.0.ip6.arpa { };' in named.conf. You need @ IN PTR localhost. not 1 IN PTR localhost.. This puts the PTR record at the top of the zone not one label further down. Also make sure the IPv4 reverse zone is called 1.0.0.127.in-addr.arpa, not 0.0.127.in-addr.arpa, if it is using the same master file. Thank You, Casey ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TXT Record Format with multiple records?
On Oct 12 2013, John Levine wrote: Please forgive my ignorance, and sorry about all the details. I have not been able to find a detailed specification. TXT records haven't changed since RFC 1034 and 1035. You can have multiple strings per record, and multiple records per name. At the application level, some applications glom multiple strings per record together, some treat them separately. There are a few obscure designs that combine multiple TXT records at the same name, but you're unlikely to run into any of them. If you do use multiple TXT records, rather than multiple strings within a single record, bear in mind that the order that the user/application will see them is TAIAP unpredictable. You don't want to end up with message.example. TXT is displayed in the right message.example. TXT only makes sense when it message.example. TXT order! message.example. TXT A paragraph of text that -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TXT Record Format with multiple records?
In message CAH8yC8mWS=kypska2qv2r-stctw_mhhyprn42aa_cm1y7+0...@mail.gmail.com , Jeffrey Walton writes: plugh.example TXT foo bar Thanks John. So I'm clear: (1) there is only one TXT record per host; No. (2) multiple TXT records are not allowed; No. and (3) the individual character strings are delimited with the quote character. Yes and no. Related: is there an escape character so a quote can be present in the character-string? Yes, back slash. Related: is the single quote also accetped? What happens if the string is Knuth said, 'random numbers should not be generated with a method chosen at random.' Finally, is there a standard document that calls the convention out? Yes. RFC 1035 Section 5.1. Format. character-string is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a and ending with a . Inside a delimited string any character can occur, except for a itself, which must be quoted using \ (back slash). Which is combined with the following to allow any 8 bit character and to allow back slash to exist in a character-string. Note the escape conventions are not the same a in C. \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, \. can be used to place a dot character in a label. \DDDwhere each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. Mark Please forgive my ignorance, and sorry about all the details. I have not been able to find a detailed specification. Jeff On Sat, Oct 12, 2013 at 12:52 AM, John Levine jo...@iecc.com wrote: How, precisely, is the second (or third) string added? plugh.example TXT foo bar ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TXT Record Format with multiple records?
Please forgive my ignorance, and sorry about all the details. I have not been able to find a detailed specification. TXT records haven't changed since RFC 1034 and 1035. You can have multiple strings per record, and multiple records per name. At the application level, some applications glom multiple strings per record together, some treat them separately. There are a few obscure designs that combine multiple TXT records at the same name, but you're unlikely to run into any of them. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TXT Record Format with multiple records?
How, precisely, is the second (or third) string added? plugh.example TXT foo bar ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TXT Record Format with multiple records?
plugh.example TXT foo bar Thanks John. So I'm clear: (1) there is only one TXT record per host; (2) multiple TXT records are not allowed; and (3) the individual character strings are delimited with the quote character. Related: is there an escape character so a quote can be present in the character-string? Related: is the single quote also accetped? What happens if the string is Knuth said, 'random numbers should not be generated with a method chosen at random.' Finally, is there a standard document that calls the convention out? Please forgive my ignorance, and sorry about all the details. I have not been able to find a detailed specification. Jeff On Sat, Oct 12, 2013 at 12:52 AM, John Levine jo...@iecc.com wrote: How, precisely, is the second (or third) string added? plugh.example TXT foo bar ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NS record TTL versus nameserver's A record TTL
Hi John, El 2013-10-08 11:49:24, John Wobus escribió: They took responsibility for their nameserver's deficiency, but it makes me wonder: -Is this addressed by a standard? E.g., the nameserver's A record have the same TTL as NS records pointing at it. -Is this addressed by a best practice? I don't of any standard addressing this. Neither I know a best practice document on this. But due to my experience, it is a quite common practice to have longer TTL on NS records than on A records. I consider this quite normal, as often you will more often change individual host's IP address than the addresses of your nameservers. Setting longer TTLs on the NS records reduces load on the higher level DNS servers while allowing you to update entries in your zone faster. For example DynDNS uses a TTL of 60 seconds for their customer's A records while having a TTL value of 86400 seconds (1 day) on their NS records. Regards, Matthias -- Matthias Wimmer Contact details: http://matthias.wimmer.tel/ smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NS record TTL versus nameserver's A record TTL
On 08.10.13 11:49, John Wobus wrote: We received a report that a domain we serve was not resolving at a remote site. The site also reported their own analysis that the issue appeared to be that the domain's NS record had a longer TTL than its target nameserver's A record and their caching server didn't seem able to handle this. FYI, the nameserver was not within the domain with the issue. it's hard to say from this information. Maybe if you provided concrete domain name(s) we could tell more. They took responsibility for their nameserver's deficiency, but it makes me wonder: -Is this addressed by a standard? E.g., the nameserver's A record have the same TTL as NS records pointing at it. It should be the same, when the server is in the domain. I met exactly those issues when NS record had longer ttl then the A record in the same domain. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF record with include:
On Jun 20, 2013, at 7:30 PM, Julie Xu j...@uws.edu.au wrote: Hi Steven, Jason, Ged and Bind expert Thanks for the reply. It is great help. However, I need ask more. For this include clause to be added in, I have also need to add DKIM records. SPF and DKIM are unrelated. There is no way to reference DKIM records inside your SPF records. Chris ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SPF record with include:
Hi Steven, Jason, Ged and Bind expert Thanks for the reply. It is great help. However, I need ask more. For this include clause to be added in, I have also need to add DKIM records. we do not use it currently, which means the mx part do not use, but include part will use it. Could I get advice on if the DKIM records will impact the email service which related to mx related environment? Thousands thanks for advice Julie -Original Message- From: Steven Carr [mailto:sjc...@gmail.com] Sent: Tuesday, 18 June 2013 4:11 PM To: Julie Xu Cc: bind-users@lists.isc.org Subject: Re: SPF record with include: Remove the part... http://otheremailsrv.otherdomain, whatever mailer agent you use has screwed with the information that you were sent, it is not required. So your finished TXT record will be... TXT v=spf1 mx include:otheremailsrv.otherdomain ~all Steve On 18 June 2013 06:56, Julie Xu j...@uws.edu.au wrote: Hi I be asked to add: include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain so the TXT records will be looked like: TXT v=spf1 mx include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain ~all Question, from my limited research, I have not found any example to put http part into TXT records, and a little bit worried. Could any one advice me if I can put http in spf record like above? If so, is my statement right? Any comments will be appreciated Thanks in advance julie ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF record with include:
Remove the part... http://otheremailsrv.otherdomain, whatever mailer agent you use has screwed with the information that you were sent, it is not required. So your finished TXT record will be... TXT v=spf1 mx include:otheremailsrv.otherdomain ~all Steve On 18 June 2013 06:56, Julie Xu j...@uws.edu.au wrote: Hi I be asked to add: include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain so the TXT records will be looked like: TXT v=spf1 mx include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain ~all Question, from my limited research, I have not found any example to put http part into TXT records, and a little bit worried. Could any one advice me if I can put http in spf record like above? If so, is my statement right? Any comments will be appreciated Thanks in advance julie ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF record with include:
Really I can't see as it would hurt in either SPF/SPF or SPF/TXT To me it looks to just be a referring URL for those that get a reject based on the SPF rule. Kinda like a comment judging by . I've not seen it in the wild this far besides this case. Not even in the google for business app references. Personally I would just drop the http URL and angles. Thus far I've only really had to use ip4 and 'a' and 'redirect' with no complaints. -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 18, 2013, at 1:56, Julie Xu j...@uws.edu.au wrote: Hi I be asked to add: include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain so the TXT records will be looked like: TXT v=spf1 mx include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain ~all Question, from my limited research, I have not found any example to put http part into TXT records, and a little bit worried. Could any one advice me if I can put http in spf record like above? If so, is my statement right? Any comments will be appreciated Thanks in advance julie ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF record with include:
Hi there, On Tue, 18 Jun 2013, Julie Xu wrote: I be asked to add: include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain so the TXT records will be looked like: TXT v=spf1 mx include:otheremailsrv.otherdomainhttp://otheremailsrv.otherdomain ~all Question, from my limited research, I have not found any example to put http part into TXT records, and a little bit worried. Could any one advice me if I can put http in spf record like above? No, you cannot do that. Also you should not use the 'mx mechanism' unless you really know what you are doing. It is almost always a bad idea, not least because it wastes bandwidth. It might be better to ask your question at spf-h...@listbox.com, but PLEASE use real domain names in future when you ask your questions, it is difficult to answer this kind of question without that information. -- 73, Ged. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cname record
Hi, Dwayne-- On Mar 1, 2013, at 10:29 AM, Dwayne Hottinger wrote: I would like for users inside my network to not be able to do ssl searches with google, because of cipa compliance issues. OK, so you should block port tcp/443 to Google's network addresses (approximately 173.194.79.0/24) on your firewall. I added a cname record to my zone file: www.google.com CNAME nosslsearch.google.com To try and get it to redirect. Since Im not authoritive for google, I dont think this will work no matter how I tweak it. Am I right in this assumption? You can use RPZ capabilities in BIND to override their records: http://www.isc.org/software/rpz ...but that won't do anything to prevent a knowledgeable user from hitting something like https://173.194.79.99/ directly. Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record TTL question.
Hmm... so what tool adds the DS key? I never use the dnssec-signzone tool, so that's not it right? What I want is for the DS record to its TTL the same as the rest of the zone entries. -- Bryan S.G. On Thu, Aug 9, 2012 at 1:26 PM, Mark Andrews ma...@isc.org wrote: In message caektliseakw-xskaetgd7twkxuaxrkywyakybg2de_16trv...@mail.gmail.com , Casey Deccio writes: On Wed, Aug 8, 2012 at 9:36 AM, GS Bryan chif...@anime.my wrote: My question is how can I control the TTL of the DS record inserted into a signed zone via inline signing? I'm using BIND 9.9.1 P2. My zone file has a default TTL of 3600 a.k.a. 1 hour, but it seems the 2 DS records put into the signed version of the zone has the TTL of 1 day. I would like that the zone default TTL be obeyed when the DS records are being inserted during inline signing. I don't know about BIND's default behavior for DS TTL or its options for customizing the TTL, but according to RFC 4035 (Section 2.4): The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset). Casey Named doesn't add DS record as part of the inline signing process. You need to look at the tool used to add the DS records. Inline signing adds DNSKEY, NSEC, NSEC3 and NSEC3PARAM records. DS is just data as far as inline signing is concerned. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record TTL question.
In message caoj-cljgjtj_qm2pnfi3iv_0zzfxesnk9upuahhr-sukahr...@mail.gmail.com , GS Bryan writes: Hmm... so what tool adds the DS key? I never use the dnssec-signzone tool, so that's not it right? What I want is for the DS record to its TTL the same as the rest of the zone entries. -- Bryan S.G. I don't know what tool you used. If you are maintaining the records by hand then you probably cut-and-pasted the records along with a explicit TTL. If you used nsupdate then the TTL was specified in the update request. Mark On Thu, Aug 9, 2012 at 1:26 PM, Mark Andrews ma...@isc.org wrote: In message CAEKtLiSEAkw-XskaeTgd7twkXUaxrkywYAkyBg2DE_16tRv61Q@mail.gmail. com , Casey Deccio writes: On Wed, Aug 8, 2012 at 9:36 AM, GS Bryan chif...@anime.my wrote: My question is how can I control the TTL of the DS record inserted into a signed zone via inline signing? I'm using BIND 9.9.1 P2. My zone file has a default TTL of 3600 a.k.a. 1 hour, but it seems the 2 DS records put into the signed version of the zone has the TTL of 1 day. I would like that the zone default TTL be obeyed when the DS records are being inserted during inline signing. I don't know about BIND's default behavior for DS TTL or its options for customizing the TTL, but according to RFC 4035 (Section 2.4): The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset (that is, the NS RRset from the same zone containing the DS RRset). Casey Named doesn't add DS record as part of the inline signing process. You need to look at the tool used to add the DS records. Inline signing adds DNSKEY, NSEC, NSEC3 and NSEC3PARAM records. DS is just data as far as inline signing is concerned. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NS record for subzone definition
On Tue, Mar 13, 2012 at 9:33 AM, hugo hugoo hugo...@hotmail.com wrote: Thanks for this interesting feedback. Now I have the problem to detect this kind of bad configuration. If I have: Zone toto.be: toto.be. NS ns1.xxx.be + some records Zone titi.toto.be: titi.toto.be. NS ns1.xxx.be + some records. What will be the command to detect that zone toto.be has no NS for titi.toto.be ?? Here's one command, given that ns1.xxx.be is authoritative for both toto.beand titi.toto.be: dig +noall +comments @ns1.xxx.be titi.toto.be ns | grep status: NOERROR \ dig +noall +comments @ns1.xxx.be titi.toto.be ds | grep status: NXDOMAIN A zero exit status for the above command indicates that the NS RRs are missing from the parent. Note, however, that a non-zero exit status doesn't necessarily mean that the NS records exist. Casey ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users